Method and apparatus of transmitting control information in wireless communication systems

ABSTRACT

The present disclosure relates to communication schemes for combining 5G communication systems with IoT technology to support higher data transmission rate as post-4G systems and systems for the same. The present disclosure may be used in intelligent services (e.g., smart home, smart building, smart city, smart car, or connected car, health-care, digital education, retail business, security and safety-related services, etc.) based on the 5G communication technology and IoT-related techniques. According to an embodiment of the present disclosure, a method for transmitting control information in a wireless communication system comprises generating a header including a plurality of MAC subheaders and a medium access control (MAC) control information including a control field indicating whether there are included information related to a power headroom for a primary cell (PCell) and information regarding secondary cells (SCells) reportable to an extended power headroom and transmitting a payload including the MAC control information and the header, wherein the control field indicating activation or deactivation of at least one of the SCells.

PRIORITY

This application claims the benefit under 35 U.S.C. §119(e) to a USpatent application filed in the United States Patent and TrademarkOffice on Jan. 16, 2015 and assigned Ser. No. 62/104,320, a US patentapplication filed in the United States Patent and Trademark Office onFeb. 6, 2015 and assigned Ser. No. 62/112,986, and a US patentapplication filed in the United States Patent and Trademark Office onJul. 20, 2015 and assigned Ser. No. 62/194,632, the entire disclosure ofeach of which is hereby incorporated by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present disclosure relates to methods and apparatuses fortransmitting control information in wireless communication systems.

2. Description of the Related Art

In order to meet the demand for wireless data traffic soring since the4G communication system came to the market, there are ongoing efforts todevelop enhanced 5G communication systems or pre-5G communicationsystems. For the reasons, the 5G communication system or pre-5Gcommunication system is called the beyond 4G network communicationsystem or post LTE system. For higher data transmit rates, 5Gcommunication systems are considered to be implemented on ultra highfrequency bands (mmWave), such as, e.g., 60 GHz. To mitigate pathloss onthe ultra high frequency band and increase the reach of radio waves, thefollowing techniques are taken into account for the 5G communicationsystem: beamforming, massive multi-input multi-output (MIMO), fulldimensional MIMO (FD-MIMO), array antenna, analog beamforming, and largescale antenna. Also being developed are various technologies for the 5Gcommunication system to have an enhanced network, such as evolved oradvanced small cell, cloud radio access network (cloud RAN), ultra-densenetwork, device-to-device (D2D) communication, wireless backhaul, movingnetwork, cooperative communication, coordinated multi-point (CoMP), andinterference cancellation. There are also other various schemes underdevelopment for the 5G system including, e.g., hybrid FSK and QAMmodulation (FQAM) and sliding window superposition coding (SWSC), whichare advanced coding modulation (ACM) schemes, and filter bankmulti-carrier (FBMC), non-orthogonal multiple access (NOMA) and sparsecode multiple access (SCMA), which are advanced access schemes.

The Internet is evolving from the human-centered connection network bywhich humans create and consume information to the Internet of Things(IoT) network by which information is communicated and processed betweenthings or other distributed components. Another arising technology isthe Internet of Everything (IoE), which is a combination of the Big dataprocessing technology and the IoT technology through, e.g., a connectionwith a cloud server. To implement the IoT, technology elements, such asa sensing technology, wired/wireless communication and network infra,service interface technology, and a security technology, are required.There is a recent ongoing research for inter-object connectiontechnologies, such as the sensor network, Machine-to-Machine (M2M), orthe Machine-Type Communication (MTC). In the IoT environment may beoffered intelligent Internet Technology (IT) services that collect andanalyze the data generated by the things connected with one another tocreate human life a new value. The IoT may have various applications,such as the smart home, smart building, smart city, smart car orconnected car, smart grid, health-care, or smart appliance industry, orstate-of-art medical services, through conversion or integration ofgeneral information technology (IT) techniques and various industries.

Thus, there are various ongoing efforts to apply the 5G communicationsystem to the IoT network. For example, the sensor network,machine-to-machine (M2M), machine type communication (MTC), or other 5Gtechniques are implemented by schemes, such as beamforming, multi-inputmulti-output (MIMO), and array antenna schemes. The above-mentionedapplication of the cloud radio access network (RAN) as a Big dataprocessing technique may be said to be an example of the convergence ofthe 5G and IoT technologies.

Meanwhile, a critical requirement for next-generation wirelesscommunication systems is, among others, to support the demand of highdata transmission rates. To that end, various techniques includingmultiple input multiple output (MIMO), cooperative multiple pointtransmission (CoMP), and relay are being researched, but the mostfundamental and stable solution is to increase bandwidth.

However, frequency resources have been saturated as of today, and thewide frequency band is partially being used for various techniques. Forthat reason, carrier aggregation (CA) is adopted as an approach tosecure a wide bandwidth to meet the demand for high data transmission.In CA, dispersed bandwidths each are designed to meet basic requirementsto operate an independent system, and such multiple bandwidths arebundled into one system. Next-generation wireless communication systemsrequire specific schemes to meet service requirements.

The above information is presented as background information only toassist with an understanding of the present disclosure. No determinationhas been made, and no assertion is made, as to whether any of the abovemight be applicable as prior art with regard to the present disclosure.

SUMMARY OF INVENTION

According to the present disclosure, there are provided a method andapparatus for addressing the problem that inclusion of the Ci of theSCell and its corresponding PH information may bring about unneglectablesignaling overhead particularly under the circumstance where the numberof DL only SCells increases.

According to the present disclosure, there are provided a method andapparatus for performing machine-type communication.

According to the present disclosure, there are provided a method andapparatus for supporting access by a machine-type communication (MTC)terminal considering the features of the MTC terminal.

According to the present disclosure, there are provided a method andapparatus for providing an efficient procedure for an MTC terminal uponrandom access to access a base station.

According to the present disclosure, there are provided a method andapparatus utilizing a token upon access an IMS through WebRTC access ina web type.

According to an embodiment of the present disclosure, a method fortransmitting control information in a wireless communication systemcomprises generating a header including a plurality of MAC subheadersand a medium access control (MAC) control information including acontrol field indicating whether there are included information relatedto a power headroom for a primary cell (PCell) and information regardingsecondary cells (SCells) reportable to an extended power headroom andtransmitting a payload including the MAC control information and theheader, wherein the control field indicating activation or deactivationof at least one of the SCells.

According to an embodiment of the present disclosure, an apparatus fortransmitting control information in a wireless communication systemcomprises a controller generating a header including a plurality of MACsubheaders and a medium access control (MAC) control informationincluding a control field indicating whether there are includedinformation related to a power headroom for a primary cell (PCell) andinformation regarding secondary cells (SCells) reportable to an extendedpower headroom and a transmitter transmitting a payload including theMAC control information and the header, wherein the control fieldindicating activation or deactivation of at least one of the SCells.

Other aspects, advantages, and salient features of the disclosure willbecome apparent to those skilled in the art from the following detaileddescription, which, taken in conjunction with the annexed drawings,discloses exemplary embodiments of the disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a view illustrating a structure of a LTE mobile communicationsystem;

FIG. 2 is a view illustrating an exemplary LTE CA function;

FIGS. 3A and 3B are views illustrating examples of an extended PHR MACcontrol information format available in LTE CA;

FIG. 4 is a view illustrating an example of an activation/deactivationMAC control information format;

FIGS. 5A and 5B are views illustrating examples of an enhanced extendedPHR control information format supporting up to 32 serving cellsaccording to a third embodiment of the present disclosure;

FIGS. 6A and 6B are views illustrating examples of an MACactivation/deactivation control information format;

FIG. 7 is a block diagram illustrating a configuration of a terminalaccording to an embodiment of the present disclosure;

FIG. 8 is a view illustrating the radio protocol structure in an LTEsystem according to an embodiment of the present disclosure.

FIG. 9 is a view illustrating enhanced carrier aggregation for aterminal;

FIG. 10 is a view illustrating a process of activating PUCCH SCell whenfollowing a normal SCell activation process;

FIG. 11 is a view illustrating an example of a legacy A/D MAC CE format;

FIG. 12 is a view illustrating an example of an extended A/D MAC CEformat for supporting up to 32 serving cells;

FIG. 13 is a view illustrating a method for selecting a normal orextended A/D MAC CE according to an embodiment of the presentdisclosure;

FIG. 14 is a flowchart illustrating an operation of a base stationaccording to an embodiment of the present disclosure;

FIG. 15 is a flowchart illustrating an operation of a terminal accordingto a first embodiment of the present disclosure;

FIG. 16 is a block diagram illustrating a configuration of a terminalaccording to an embodiment of the present disclosure;

FIG. 17 is a view illustrating a process of obtaining system informationfrom a base station and performing access by a machine-typecommunication device;

FIG. 18 is a view illustrating a method of obtaining system informationfrom a base station by a machine-type communication device according toa fifth embodiment of the present disclosure;

FIG. 19 is a view illustrating a method of obtaining system informationfrom a base station by a machine-type communication device according toa sixth embodiment of the present disclosure;

FIG. 20 is a view illustrating an MTC EPDCCH transmitted through apredetermined radio resource according to an embodiment of the presentdisclosure;

FIG. 21 is a view illustrating a method of obtaining system informationfrom a base station by a machine-type communication device according toa seventh embodiment of the present disclosure;

FIG. 22 is a view illustrating a method of updating system informationaccording to an eighth embodiment of the present disclosure;

FIG. 23 is a view illustrating a method of updating system informationaccording to a ninth embodiment of the present disclosure;

FIG. 24 is a view illustrating a legacy RACH process and a method ofcomputing RA-RNTI;

FIG. 25 is a view illustrating an RACH process according to anembodiment of the present disclosure;

FIG. 26 is a view illustrating a method of selecting a subband to beused for access by each machine-type communication device according toan embodiment of the present disclosure;

FIG. 27 is a view illustrating an operation of a terminal reselecting aproper cell when reselecting a cell among cells belonging to a frequencywith the same priority or the same frequency according to the presentdisclosure;

FIG. 28 is a flowchart illustrating a contention-based random accessprocedure used in an LTE system;

FIG. 29 is a view illustrating a frame structure according to anembodiment of the present disclosure;

FIG. 30 is a flowchart illustrating a message flow of a random accessprocedure of an MTC terminal as proposed on the frame structuredescribed in connection with FIG. 29 according to a tenth embodiment ofthe present disclosure;

FIG. 31 is a flowchart illustrating an operation of a terminal to whichthe tenth embodiment of the random access procedure of the MTC terminalapplies according to an embodiment of the present disclosure;

FIG. 32 is a view illustrating a frame structure according to anembodiment of the present disclosure;

FIG. 33 is a flowchart illustrating a message flow of a random accessprocedure of an MTC terminal as proposed on the frame structuredescribed in connection with FIG. 32 according to an eleventh embodimentof the present disclosure;

FIG. 34 is a flowchart illustrating an operation of a terminal to whichthe eleventh embodiment of the random access procedure of the MTCterminal applies according to an embodiment of the present disclosure;

FIG. 35 is a flowchart illustrating a message flow of a random accessprocedure of an MTC terminal as proposed on the frame structuredescribed in connection with FIG. 32 according to a twelfth embodimentof the present disclosure;

FIG. 36 is a flowchart illustrating an operation of a terminal to whichthe twelfth embodiment of the random access procedure of the MTCterminal applies according to an embodiment of the present disclosure;

FIG. 37 is a block diagram illustrating an internal structure of aterminal according to an embodiment of the present disclosure;

FIG. 38 is a block diagram illustrating an internal structure of a basestation according to an embodiment of the present disclosure; and

FIG. 39 is a flowchart illustrating a process of registering to an IMSby a WIC according to an embodiment of the present disclosure.

Throughout the drawings, like reference numerals will be understood torefer to like parts, components, and structures.

DETAILED DESCRIPTION OF THE EXEMPLARY EMBODIMENTS

Hereinafter, embodiments of the present disclosure are described indetail with reference to the accompanying drawings. The same referencedenotations may be used to refer to the same or similar elementsthroughout the specification and the drawings. When making the gist ofthe present disclosure unclear, the detailed description of knownfunctions or configurations is skipped.

The terms or language used herein should not be interpreted as limitedas typical ones or ones defined in the dictionary but rather to complywith the technical spirit of the present disclosure based on thedoctrine that the inventor may define terms on his own in a propermanner so as to make the invention understood in a best way to describebest the invention.

The terms as used herein are provided merely to describe someembodiments thereof, but not to limit the present disclosure. It is tobe understood that the singular forms “a,” “an,” and “the” includeplural references unless the context clearly dictates otherwise. It willbe further understood that the terms “comprise” and/or “have,” when usedin this specification, specify the presence of stated features,integers, steps, operations, elements, and/or components, but do notpreclude the presence or addition of one or more other features,integers, steps, operations, elements, components, and/or groupsthereof.

Unless otherwise defined, all terms including technical and scientificterms used herein have the same meaning as commonly understood by one ofordinary skill in the art to which the embodiments of the presentdisclosure belong. It will be further understood that terms, such asthose defined in commonly used dictionaries, should be interpreted ashaving a meaning that is consistent with their meaning in the context ofthe relevant art and will not be interpreted in an idealized or overlyformal sense unless expressly so defined herein.

The following description encompasses exemplary systems, methods,techniques, command sequences, and computer program articles forimplementing the subject matter of the present disclosure. However, itshould be noted that the specific embodiments may be executed withoutthe detailed description thereof. For example, although the embodimentsare involved in using LTE technologies between the base station and theterminal, the specific embodiments are not limited thereto. In otherimplementations, other proper communication standards and techniques mayalso come in use.

FIG. 1 illustrates an embodiment of an LTE mobile communication systemstructure.

Referring to FIG. 1, a radio access network of the LTE mobilecommunication system includes next-generation base stations (evolvednode B—hereinafter, “ENB” or “base station”) 105, 110, 115, and 120, amobility management entity (MME) 125, and a serving gateway (S-GW) 130.A user equipment (hereinafter, “UE” or “terminal”) 135 accesses anexternal network through the ENB and the S-GW. The ENBs 105 to 120correspond to node Bs in the legacy universal mobile telecommunicationsystem (UMTS) system. The ENBs 105 to 120 are connected with the UE 135through a wireless channel and plays a more complicated role than thelegacy node B. Since in LTE all user traffic as well as real-timeservices, such as voice over Internet protocol (VoIP) service through anInternet protocol is serviced through a shared channel, there is neededan apparatus that performs scheduling by compiling state information,regarding UEs and the ENBs 105 to 120 are in charge of the same. One ENBtypically controls multiple cells. The LTE adopts, as a radio accesstechnology, orthogonal frequency division multiplexing (hereinafter,“OFDM”) on up to a 20 MHz bandwidth in order to implement a transmissionspeed up to 100 Mbps. Further, the system applies adaptive modulation &coding (AMC) that determines a modulation scheme and a channel codingrate in compliance with the channel state of the UE. The S-GW is adevice providing a data bearer, and the serving gateway 130 generates orremoves a data bearer under the control of the MME. The MME is anapparatus that is in charge of various control functions and isconnected with multiple base stations.

FIG. 2 is a view illustrating an exemplary LTE CA function.

Generally, one base station may operate several frequencies (having thesame meaning as carrier, hereinafter interchangeably used). For example,when the base station 205 operates downlink (forward or DL) frequencywith a center frequency of fl and downlink frequency with a centerfrequency of f3 210, one terminal receives data using one of the twofrequencies according to the prior art.

However, a terminal supporting CA may receive data using both thefrequencies to increase data reception speed. The same principle givenfor downlink frequencies may also apply to uplink (backward or UL)frequencies, and terminal supporting CA may transmit data using aplurality of uplink frequencies to increase transmission data speed.From a traditional point of view, when one downlink frequency and oneuplink frequency which are transmitted or received by one base stationconfigure one cell, the CA function may be deemed as the terminaltransmitting data through a plurality of cells simultaneously. Here, theterminal may have a plurality of serving cells. Among the plurality ofserving cells, the basic sec for mobility support of terminal, cipheringof data/control information, and integrity check is denoted PCell, andother serving cells added for CA function are denoted SCells. See thefollowing for more detailed definitions of serving cell, PCell, andSCell.

Serving Cell, For a UE in RRC_CONNECTED not configured with CA there isonly one serving cell comprising of the primary cell. For a UE inRRC_CONNECTED configured with CA the term ‘serving cells’ is used todenote the set of one or more cells comprising of the primary cell andall secondary cells.

Primary Cell(PCell), The cell, operating on the primary frequency, inwhich the UE either performs the initial connection establishmentprocedure or initiates the connection re-establishment procedure, or thecell indicated as the primary cell in the handover procedure.

Secondary Cell(SCell), A cell, operating on a secondary frequency, whichmay be configured once an RRC connection is established and which may beused to provide additional radio resources.

Meanwhile, backward transmission interferes with backward transmissionof other cells, and thus, power of backward transmission should remainat a proper level. To that end, the terminal calculates a backwardtransmission power using a predetermined function when performingbackward transmission and performs backward transmission with thecalculated backward transmission power. For example, the terminal mayput in the predetermined function input values by which it may estimatechannel status such as path loss value and scheduling information suchas MCS (modulation coding scheme) to be applied and the amount oftransmission resources allocated to calculate a required backwardtransmit power value and applies the calculated required backwardtransmit power value to perform backward transmission. The backwardtransmit power value applicable by the terminal is limited by theterminal's maximum transmission value, and if the calculated requiredtransmit power value exceeds the terminal's maximum transmission value,the terminal applies the maximum transmit value to perform backwardtransmission. In such case, since it cannot apply sufficient backwardtransmit power, backward transmission quality may be deteriorated. Thebase station preferably performs scheduling so that the requiredtransmit power does not exceed the maximum transmit power. However, someparameters including pathloss cannot be grasped by the base station, andterminal reports its available transmit power (power headroom, PH)information to the base station by transmitting (extended) powerheadroom report (PHR) MAC control information. CA-operating terminal mayinclude PH information for several serving cells in a single PHR andtransmit the same, and the PHR is referred to as extended PHR.

FIGS. 3A and 3B are views illustrating a first embodiment of an extendedPHR MAC control information format available in LTE CA.

MAC header includes a sub-header for extended PHR. In FIG. 3A, it isassumed that the MAC Control element 2 310 is extended PHR MAC controlinformation, and of the MAC sub-headers, the second MAC sub-header 320is sub-header for PHR MAC CE (control element). The second MACsub-header 320 includes LCID (Logical Channel ID) (e.g., LCID value“11001”) indicating that the extended PHR is included in the MAC payloadand L that is a value indicating the size of PHR. The LCID value denoteswhether activation/deactivation is included in the MAC payload.

The extended PHR MAC control information 310 includes PCell Type2 PH,PCell Type1 PH, and SCell PHs. As shown in FIG. 3B, in the continuousbytes, the extended PHR MAC control information 310 includes, as the PHinformation of each cell, PCell's Type 2 PH→PCell's Type 1 PH→firstSCell's PH→second SCell's PH→third SCell's PH→fourth SCell's PH→, . . .. The extended PHR MAC control information always includes the PHinformation on the PCell, and which SCell the included PH information isabout is indicated by the ‘C’ field.

FIG. 4 is a view illustrating a second embodiment of theactivation/deactivation MAC control information format.

The second MAC sub-header 420 includes an LCID (e.g., LCID value“11001”) indicating that the extended PHR is included in the MAC payloadand L that is a value indicating the size of PHR. The LCID value denoteswhether activation/deactivation is included in the MAC payload.

The definition of each field in the MAC subheader is as follows. See3GPP standard TS36.321 for details.

The MAC header is of variable size and consists of the following fields,

-   -   LCID: The Logical Channel ID field identifies the logical        channel instance of the corresponding MAC SDU or the type of the        corresponding MAC control element or padding as described in        tables 6.2.1-1, 6.2.1-2 and 6.2.1-4 for the DL-SCH, UL-SCH and        MCH respectively. There is one LCID field for each MAC SDU, MAC        control element or padding included in the MAC PDU. In addition        to that, one or two additional LCID fields are included in the        MAC PDU, when single-byte or two-byte padding is required but        cannot be achieved by padding at the end of the MAC PDU. The        LCID field size is 5 bits,    -   L: The Length field indicates the length of the corresponding        MAC SDU or variable-sized MAC control element in bytes. There is        one L field per MAC PDU subheader except for the last subheader        and subheaders corresponding to fixed-sized MAC control        elements. The size of the L field is indicated by the F field,    -   F: The Format field indicates the size of the Length field as        indicated in table 6.2.1-3. There is one F field per MAC PDU        subheader except for the last subheader and subheaders        corresponding to fixed-sized MAC control elements. The size of        the F field is 1 bit. If the size of the MAC SDU or        variable-sized MAC control element is less than 128 bytes, the        value of the F field is set to 0, otherwise it is set to 1,    -   E: The Extension field is a flag indicating if more fields are        present in the MAC header or not. The E field is set to “1” to        indicate another set of at least R/R/E/LCID fields. The E field        is set to “0” to indicate that either a MAC SDU, a MAC control        element or padding starts at the next byte,    -   R: Reserved bit, set to “0”.

The MAC header and subheaders are octet aligned.

Meanwhile, the table indicating LCID for DL-SCH is as follows.

TABLE 1 Index LCID values 00000 CCCH 00001-01010 Identity of the logicalchannel 01011-11001 Reserved 11010 Long DRX Command 11011activation/deactivation 11100 UE Contention Resolution Identity 11101Timing Advance Command 11110 DRX Command 11111 Padding

Referring to Table 1, the LCID value of 11011 denotes whetheractivation/deactivation is included in the MAC payload.

The table indicating LCID for UL-SCH is as follows.

TABLE 2 Index LCID values 00000 CCCH 00001-01010 Identity of the logicalchannel 01011-11000 Reserved 11001 Extended Power Headroom Report 11010Power Headroom Report 11011 C-RNTI 11100 Truncated BSR 11101 Short BSR11110 Long BSR 11111 Padding

The table indicating F field is as follows.

TABLE 3 Index Size of Length field (in bits) 0 7 1 15

Each field included in the extended PHR is now described. See 3GPPstandard TS36.321 for details.

The Extended Power Headroom Report(PHR) MAC control element isidentified by a MAC PDU subheader with LCID as specified in table6.2.1-2. It has a variable size and is defined in FIG. 6.1.3.6 a-2. WhenType 2 PH is reported, the octet containing the Type 2 PH field isincluded first after the octet indicating the presence of PH per SCelland followed by an octet containing the associated P_(CMAX,c) field (ifreported). Then follows in ascending order based on the ServCellIndex[8] an octet with the Type 1 PH field and an octet with the associatedP_(CMAX,c) field (if reported), for the PCell and for each SCellindicated in the bitmap.

The Extended PHR MAC Control Element is defined as follows,

-   -   C_(i): this field indicates the presence of a PH field for the        SCell with SCellIndex i as specified in [8]. The C_(i) field set        to “1” indicates that a PH field for the SCell with SCellIndex i        is reported. The C_(i) field set to “0” indicates that a PH        field for the SCell with SCellIndex i is not reported,    -   R: reserved bit, set to “0”,    -   V: this field indicates if the PH value is based on a real        transmission or a reference format. For Type 1 PH, V=0 indicates        real transmission on PUSCH and V=1 indicates that a PUSCH        reference format is used. For Type 2 PH, V=0 indicates real        transmission on PUCCH and V=1 indicates that a PUCCH reference        format is used. Furthermore, for both Type 1 and Type 2 PH, V=0        indicates the presence of the octet containing the associated        P_(CMAX,c) field, and V=1 indicates that the octet containing        the associated P_(CMAX,c) field is omitted,    -   Power Headroom(PH): this field indicates the power headroom        level. The length of the field is 6 bits. The reported PH and        the corresponding power headroom levels are shown in Table        6.1.3.6-1 (the corresponding measured values in dB can be found        in subclause 9.1.8.4 of [9]),    -   P: this field indicates whether the UE applies power backoff due        to power management (as allowed by P-MPR_(c) [10]). The UE shall        set P=1 if the corresponding P_(CMAX,c) field would have had a        different value if no power backoff due to power management had        been applied,    -   P_(CMAX,c): if present, this field indicates the P_(CMAX,c) or        {tilde over (P)}_(CMAX,c)[2] used for calculation of the        preceding PH field. The reported P_(CMAX,c) and the        corresponding nominal UE transmit power levels are shown in        Table 6.1.3.6a-1 (the corresponding measured values in dBm can        be found in subclause 9.6.1 of [9]).

Meanwhile, ServCellIndex applies integer ‘0’ for PCell, and SCellIndexvalue assigned when the base station adds or varies a particular Scellthrough RRC (Radio Resource Control) control message applies for SCell.As an example of RRC control message to add or vary particular SCell,RRCConnectionReconfiguration message may come in use, and of thefollowing ASN.1 code, the underlined portion shows details of signalingfor how SCellIndex is set up when a particular SCell is added or variedin ServCellIndex information and RRCConnectionReconfiguration message.SCellIndex is assigned an integer from one to seven. See 3GPP standardTS36.331 for details.

ServCellIndex is defined as follows.

ServCellIndex

The IE ServCellIndex concerns a short identity, used to identify aserving cell(i.e. the PCell or an SCell). Value 0 applies for the PCell,while the SCellIndex that has previously been assigned applies forSCells.

ServCellIndex information element is defined as follows.

ServCellIndex Information Element

TABLE 4 -- ASN1START ServCellIndex-r10 ,,=     INTEGER(0..7) -- ASN1STOP

RRCConnectionReconfiguration is defined as follows.

RRCConnectionReconfiguration

The RRCConnectionReconfiguration message is the command to modify an RRCconnection. It may convey information for measurement configuration,mobility control, radio resource configuration(including RBs, MAC mainconfiguration and physical channel configuration) including anyassociated dedicated NAS information and security configuration.

Signaling radio bearer, SRB1

RLC-SAP, AM

Logical channel, DCCH

Direction, E-UTRAN to UE

RRCConnectionReconfiguration message is defined in Tables 5 to 9. Thefollowing Tables 5 to 9 are a continuous table.

TABLE 5 -- ASN1START RRCConnectionReconfiguration ,,= SEQUENCE {  rrc-TransactionIdentifier RRC-TransactionIdentifier,  criticalExtensions CHOICE {    c1   CHOICE{     rrcConnectionReconfiguration-r8RRCConnectionReconfiguration-r8-IEs,      spare7 NULL,      spare6 NULL,spare5 NULL, spare4 NULL,      spare3 NULL, spare2 NULL, spare1 NULL   },    criticalExtensionsFuture   SEQUENCE { }   } }

TABLE 6 RRCConnectionReconfiguration-r8-IEs ,,= SEQUENCE {   measConfig  MeasConfig   OPTIONAL, -- Need ON   mobilityControlInfo  MobilityControlInfo   OPTIONAL, -- Cond HO   dedicatedInfoNASList  SEQUENCE(SIZE(1..maxDRB))   OF DedicatedInfoNAS   OPTIONAL, -- CondnonHO   radioResourceConfigDedicated   RadioResourceConfigDedicated  OPTIONAL, -- Cond HO-toEUTRA   securityConfigHO   SecurityConfigHO  OPTIONAL, -- Cond HO   nonCriticalExtensionRRCConnectionReconfiguration- v890-IEs   OPTIONAL }RRCConnectionReconfiguration-v890-IEs ,,= SEQUENCE {  lateNonCriticalExtension OCTET STRING   OPTIONAL,  nonCriticalExtension RRCConnectionReconfiguration- v920-IEs   OPTIONAL} RRCConnectionReconfiguration-v920-IEs ,,= SEQUENCE {   otherConfig-r9  OtherConfig-r9   OPTIONAL, -- Need ON   fullConfig-r9 ENUMERATED{true}   OPTIONAL, -- Cond HO-Reestab   nonCriticalExtensionRRCConnectionReconfiguration- v1020-IEs   OPTIONAL }

TABLE 7 RRCConnectionReconfiguration-v1020-IEs ,,= SEQUENCE {  sCellToReleaseList-r10   SCellToReleaseList-r10   OPTIONAL, -- Need ON  sCellToAddModList-r10 SCellToAddModList-r10 OPTIONAL, -- Need ON  nonCriticalExtension RRCConnectionReconfiguration- v1130-IEs  OPTIONAL } RRCConnectionReconfiguration-v1130-IEs ,,= SEQUENCE {  systemInfomationBlockType1Dedicated-r11  OCTET STRING(CONTAININGSystemInformationBlockType1)   nonCriticalExtensionRRCConnectionReconfiguration- v12xy-IEs   OPTIONAL  -- Need OP }RRCConnectionReconfiguration-v12xy-IEs ,,= SEQUENCE {  wlan-OffloadDedicated-r12   CHOICE {    release   NULL,    setup  SEQUENCE {      wlan-OffloadConfig-r12     WLAN-OffloadConfig-r12,     t350-r12     ENUMERATED {min5, min10, min20, min30, min60,   min120, min180, spare1}   OPTIONAL-- Need ON    }   } OPTIONAL,  nonCriticalExtension SEQUENCE { }   OPTIONAL }

TABLE 8 SCellToAddModList-r10 ,,= SEQUENCE(SIZE(1..maxSCell-r10))OF SCellToAddMod-r10 SCellToAddMod-r10 ,,= SEQUENC {   sCellIndex-r10  SCellIndex-r10,    cellIdentification-r10   SEQUENCE {   physCellId-r10      PhysCellId,    dl-CarrierFreq-r10     ARFCN-ValueEUTRA }         OPTIONAL, -- Cond SCellAdd  radioResourceConfigCommonSCell-r10  RadioResourceConfigCommonSCell-r10   OPTIONAL, -- Cond SCellAdd  radioResourceConfigDedicatedSCell-r10  RadioResourceConfigDedicatedSCell-r10   OPTIONAL, -- Cond SCellAdd2  ...,   [[ dl-CarrierFreq-v1090   ARFCN-ValueEUTRA-v9e0   OPTIONAL --Cond EARFCN-max   ]] }

TABLE 9 SCellToReleaseList-r10 ,,= SEQUENCE(SIZE(1..maxSCell-r10)) OFSCellIndex-r10 SecurityConfigHO ,,= SEQUENCE {   handoverType CHOICE {   intraLTE   SEQUENCE {      securityAlgorithmConfigSecurityAlgorithmConfig   OPTIONAL, -- Cond fullConfig     keyChangeIndicator    BOOLEAN,      nextHopChainingCount   NextHopChainingCount    },    interRAT SEQUENCE {     securityAlgorithmConfig    SecurityAlgorithmConfig,     nas-SecurityParamToEUTRA    OCTET    STRING(SIZE(6))    }   },  ... } -- ASN1STOP

RRCConnectionReconfiguration field is detailed in the following Tables10 and 11.

TABLE 10 RRCConnectionReconfiguration field descriptionsdedicatedInfoNASList This field is used to transfer UE specific NASlayer information between the network and the UE. The RRC layer istransparent for each PDU in the list. fullConfig Indicates the fullconfiguration option is applicable for the RRC ConnectionReconfiguration message. keyChangeIndicator true is used only in anintra-cell handover when a K_(eNB) key is derived from a K_(ASME) keytaken into use through the latest successful NAS SMC procedure, asdescribed in TS 33.401 [32] for K_(eNB) re-keying. false is used in anintra-LTE handover when the new K_(eNB) key is obtained from the currentK_(eNB) key or from the NH as described in TS 33.401 [32].nas-securityParamToEUTRA This field is used to transfer UE specific NASlayer information between the network and the UE. The RRC layer istransparent for this field, although it affects activation of AS-security after inter-RAT handover to E-UTRA. The content is defined inTS 24.301. nextHopChainingCount Parameter NCC, See TS 33.401 [32] t350Timer T350 as described in section 7.3. Value minN corresponds to Nminutes.

TABLE 11 Conditional presence Explanation EARFCN-max The field ismandatory present if dl-CarrierFreq-r10 is included and set tomaxEARFCN. Otherwise the field is not present. fullConfig This field ismandatory present for handover within E-UTRA when the fullConfig isincluded, otherwise it is optionally present, Need OP. HO The field ismandatory present in case of handover within E-UTRA or to E-UTRA,otherwise the field is not present. HO-Reestab This field is optionallypresent, need ON, in case of handover within E-UTRA or upon the firstreconfig- uration after RRC connection re-establishment, other- wise thefield is not present. HO-toEUTRA The field is mandatory present in caseof handover to E-UTRA or for reconfigurations when fullConfig isincluded, otherwise the field is optionally present, need ON. nonHO Thefield is not present in case of handover within E-UTRA or to E-UTRA,otherwise it is optional present, need ON. SCellAdd The field ismandatory present upon SCell addition, otherwise it is not present.SCellAdd2 The field is mandatory present upon SCell addition, otherwiseit is optionally present, need ON.

SCellIndex is briefly described below.

SCellIndex is related to a short identifier used to identify SCell.

SCellIndex information element may be represented as in the followingTable 12.

TABLE 12 [Table 10] -- ASN1START SCellIndex-r10 ,,=       INTEGER(1..7)-- ASN1STOP

As set forth above, adding/varying/releasing SCell for applying CA isperformed through RRCConnectionReconfiguration, an RRC control message.Although SCell is added through RRC control message, UE-specificdata/control message are not communicated with the added SCell. Toactually use the SCell, the base station should activate the SCell bysetting the information regarding the cell in activation/deactivationMAC control information to Activation and transmitting the same. Theterminal performs UE-specific data/control information communicationoperation in the activated SCell. Likewise, to deactivate the SCellcurrently active, the base station should activate the SCell by settingthe information regarding the cell in activation/deactivation MACcontrol information to Deactivation and transmitting the same. MACheader includes a sub-header for activation/deactivation. In FIG. 4, itis assumed that the MAC Control element 2 410 is activation/deactivationcontrol information, and of the MAC sub-headers, the second MACsub-header 420 is sub-header for activation/deactivation. The second MACsub-header 420 includes an LCID (e.g., LCID value “11011”) indicatingthat activation/deactivation is included in the MAC payload. Since,unlike the above-described extended PHR, the activation/deactivation MACcontrol information has a fixed size, there is no need for the L fieldto indicate the size of MAC control element, and thus as MAC subheaders,R/R/E/LCID format is used. Each field included in the MAC subheaders hasbeen described above in connection with extended PHR, and thedescription applies here. Each field included in theactivation/deactivation MAC control information is described below. See3GPP standard TS36.321 for details.

The activation/deactivation MAC control element is identified by a MACPDU subheader with LCID as specified in table 6.2.1-1. It has a fixedsize and consists of a single octet containing seven C-fields and oneR-field. The activation/deactivation MAC control element is defined asfollows (FIG. 6.1.3.8-1).

-   -   C_(i): if there is an SCell configured with SCellIndex i as        specified in [8], this field indicates the        activation/deactivation status of the SCell with SCellIndex i,        else the UE shall ignore the C_(i) field. The C_(i) field is set        to “1” to indicate that the SCell with SCellIndex i shall be        activated. The C_(i) field is set to “0” to indicate that the        SCell with SCellIndex i shall be deactivated,    -   R: Reserved bit, set to “0”.

Currently, the 3GPP standardization organization is discussing schemesfor applying 32 serving cells to CA as a Release (Rel.) 13 technology.As per Release 12 and its precedents, up to seven SCells may be reportedwith extended PHR or activated/deactivated with activation/deactivation.According to an embodiment of the present disclosure, there is proposeda scheme for supporting HR and activation/deactivation in case up to N(e.g., N=32) serving cells may be applied to the maximum to CA, where Nis larger than the maximum number of SCells that may be reported withlegacy extended PHR or activated/deactivated with legacyactivation/deactivation. The following embodiment assumes N=32, but Nmay have other numbers.

FIGS. 5A and 5B are views illustrating examples of an enhanced extendedPHR control information format supporting up to 32 serving cellsaccording to a third embodiment of the present disclosure.

Enhanced extended PHR is hereinafter denoted “e-extended PHR.” Referringto FIG. 5A, as the LCID included in the MAC sub-header 520, a new IDvalue may be defined to indicate that the MAC payload is e-extended PHRMAC control information, or a legacy ID value may be used to indicatethat the MAC payload is e-extended PHR MAC control information, and thesize of the e-extended PHR mAC control information may be denoted usingthe L field. Since presumably N=32, up to 31 SCells except PCell may bereported. Thus, i in ci field may be an integer in a range from 1 to 31.

Although FIG. 5B presumably illustrates that R field in the fourth byteis positioned at the MSB (most significant bit), R field may alternatelybe positioned at LSB (least significant bit). The description ofrelevant parts in connection with FIGS. 3A and 3B applies to each fieldincluded in the MAC sub-header 520 and each field in e-extended PHR MACcontrol information. Referring to FIGS. 5A and 5B, a four-byte resourceis always used for the Ci field. As an example, although CA may apply toup to 32 serving cells, CA is not always conducted with 32 servingcells. For example, only eight/16 serving cells may perform CA during aparticular time period, and in such case, the remaining Ci fields exceptthe Ci fields corresponding to SCellIndex i of the eight/16 servingcells, despite unnecessary information, should be transmitted, thuscausing waste of resources. In Release 12 and its precedents, there aremaximally seven Ci fields for CA, and waste of resources is notremarkable. However, use of up to 31 Ci fields would cause waste of agood deal of bit information.

FIGS. 6A and 6B are views illustrating examples of an MACactivation/deactivation control information format.

The MAC activation/deactivation control information format is the sameas the first byte including the Ci fields shown in FIG. 3B. The onlydifference lies in that in FIG. 3B Ci field value is set to 1 if PHinformation for SCell having corresponding SCellIndex i value isincluded or 0 if the PH information for SCell is not included, while inFIG. 6B it is set to 1 when the SCell having the correspondingSCellIndex i is activated and to 0 if the SCell is deactivated. That is,the scheme of adjusting the size of Ci fields proposed through FIG. 4,FIGS. 5A and 5B, and FIGS. 6A and 6B and the scheme as to which SCelleach CI is to be mapped/associated may apply likewise toactivation/deactivation MAC control information as well. As an example,if the method described in connection with FIGS. 5A and 5B applies toactivation/deactivation MAC control information, it may lead to thefollowing embodiment of enhanced activation/deactivation MAC controlinformation as shown in FIGS. 6A and 6B.

FIG. 7 is a block diagram illustrating a configuration of a terminalaccording to an embodiment of the present disclosure.

The terminal includes a transceiver 705, a PH calculator 715, acontroller 710, a multiplexing and demultiplexing unit 720, a controlmessage processor 735, and various higher layer units 725 and 730. Thetransceiver 705 receives data and a predetermined control signal througha forward carrier and transmits data and a predetermined control signalthrough a backward carrier. When multiple carriers are aggregated, thetransceiver 705 conducts communication of data and control signalsthrough the multiple carriers. The controller 710 instructs themultiplexing and demultiplexing unit 720 to configure MAC PDU accordingto scheduling information indicated by a control signal, e.g., abackward grant, provided from the transceiver 705. Further, thecontroller 710 determines whether to trigger PHR, and if PHR istriggered, instructs the PH to calculate available transmit power.Whether PHR is triggered is determined using a PHR parameter transferredfrom the control message processor 735. The controller 710 generates thePHR using the available transmit power transferred from the PHcalculator 715 and transfers the same to the multiplexing anddemultiplexing unit 720. The PH calculator 715 computes the availabletransmit power under the control of the controller 710 and transfers thecomputed value to the controller 710. The multiplexing anddemultiplexing unit 720 multiplexes data generated in the higher layerunits 725 and 730 or the control message processor 735 or demultiplexesdata received from the transceiver 705 and transfers the resultant datato a proper higher layer unit 725 and 730, or the control messageprocessor 735. The control message processor 735 processes controlmessages received from the network and performs necessary operations.For example, the control message processor 735 transfers the PHRparameters contained in the control message to the controller 710 ortransfers information on carriers newly activated to the transceiver 705so that the carriers are configured in the transceiver 705. The higherlayer units 725 and 730 may be configured per service, and may processdata generated in a user service such as file transfer protocol (FTP) orvoice over Internet protocol (VoIP) to transfer the same to themultiplexing device or processes data transferred from thedemultiplexing unit to transfer the same to a higher layer's serviceapplication.

FIG. 8 is a view illustrating the radio protocol structure in an LTEsystem according to an embodiment of the present disclosure. The LTEsystem wireless protocol includes packet data convergence protocols(PDCPs) 805 and 840, radio link controls (RLCs) 810 and 835, and mediumaccess controls (MACs) 815 and 830 for the UE and ENB, respectively. ThePDCPs 805 and 840 are in charge of an operation such ascompression/restoration. The RLCs 810 and 835 reconfigure packet dataunits (PDUs) into a proper size and perform ARQ operations. The MACs 815and 830 are connected to several RLC layer devices configured in one UEand multiplexes RLC PDUs into an MAC PDU and demultiplexes RCL PDUs fromthe MAC PDU. The physical layers 820 and 825 channel-code and modulatehigher layer data into OFDM symbols, transmit the OFDM symbols through awireless channel or demodulates OFDM symbols received through a wirelesschannel, channel-decodes and transfers the same to a higher layer unit.

FIG. 9 is a view illustrating enhanced carrier aggregation for aterminal.

Referring to FIG. 9, one base station generally transmits and receivesmultiple carriers over several frequency bandwidths. For example, whenthe base station 905 transmits uplink carriers for four cells, oneterminal conventionally communicates data using one of the plurality ofcells. However, a carrier aggregation-enabled UE may communicate datafrom a number of carriers at the same time. The base station 905 mayincrease the transmission speed of the UE 930 by allocating morecarriers to the carrier aggregation-enabled UE 930 depending oncircumstances. When one forward carrier and one backward carriertransmitted and received by one base station constitute one cell,carrier aggregation may be appreciated as a UE communicating datathrough several cells at the same time. Accordingly, a maximumtransmission speed is increased in proportion to the number of carriersaggregated. In LTE Rel-10 carrier aggregation technology, up to fivecells may be configured in one terminal. Among the configured cells, onecell should have PUCCH, and this cell is called a primary cell (PCell),and the remaining cells with no PUCCH are called secondary cells(SCells). The PCell, on top of the feature of having PUCCH, should beable to perform all of the normal serving cell functions such ashandover and radio link fail (RLF). Hereinafter, in embodiments of thepresent disclosure, a “UE receives data through a forward carrier ortransmits data through a backward carrier” also means that “data iscommunicated using a control channel and data channel corresponding to afrequency band and center frequency specifying the carriers. Further,although the following embodiments assume LTE systems for the purpose ofdescription, the present disclosure may also be applicable to variouswireless communication systems supporting carrier aggregation. In theRel-10 carrier aggregation technology, only PCell may have PUCCH.However, under the circumstance where more information should bedelivered through PUCCH to the base station, heavy load may be posed toprocessing the information only through a single PUCCH. In particular,the plan of supporting up to 32 carriers in LTE Rel-13 is not beingdiscussed, and allowing SCell, as well as Pcell, to have PUCCH providesbenefits, e.g., mitigating PUCCH load. Accordingly, the plan ofintroducing PUCCH to SCell as well as Pcell is being proposed. Forexample, as shown in FIG. 9, one SCell 920 may add PUCCH. According tothe present disclosure, the SCell having PUCCH is called PUCCH SCell.Conventionally, all, PUCCH-related signaling is delivered through Pcellto the base station. However, since there are now a plurality of PUCCHs,it should be needed to differentiate which PUCCH is used to transfer thePUCCH signaling of each SCell to the base station. Assuming that thereare two PUCCHs as shown in FIG. 9, there are distinguished a group 935of cells using the PUCCH of the Pcell and a group of cells using thePUCCH of a particular SCell. According to the present disclosure, suchgroup is called a PUCCH cell group.

FIG. 10 is a view illustrating a process of activating PUCCH SCell whenfollowing a normal SCell activation process.

The terminal receives an RRC message instructing to add a PUCCH SCellfrom the base station (1000). Here, the terminal configures the PUCCHSCell. When the terminal completes the configuration of the PUCCH SCell,the PUCCH SCell is in a deactivated state (1005). Thereafter, uponreception of activation/deactivation MAC control element (CE) (“A/D MACCE”) from the base station, the terminal activates the PUCCH SCell(1010). Here, the base station cannot send the A/D MAC CE to theterminal right after completing the configuration. This is why it cannotbe aware exactly when the terminal finishes preparing to receive the A/DMAC CE. Considering this, the base station thus sends the A/D MAC CE tothe terminal in a predetermined time margin. The terminal, uponcompleting the activation of the PUCCH SCell, reports the valid CSI forthe SCell and transmits the SRS (1015). After completing the activation,the base station is not aware when the terminal starts to report the CSIand transmit the SRS. Accordingly, the base station performs blinddecoding until such pieces of information are received. This brings thebase station to more complexity. Upon failure of uplink sync, the basestation additionally instructs the terminal to perform random accessthrough a PDCCH order. In such case, a more delay occurs to the CSIreporting and SRS transmission.

FIG. 11 is a view illustrating an example of a legacy A/D MAC CE format.

The A/D MAC CE has a fixed size and includes seven Ci fields 1100 andone reserved (R) field 1105. The base station transmits the A/D MAC CEto activate or deactivate the SCells configured for one terminal. EachCi field corresponds to one SCell. That is, one Ci field corresponds toan SCell denoted with SCellIndex i. The value being 1 indicates toactivate the corresponding SCell, and the value of 0 indicates todeactivate the corresponding SCell.

FIG. 12 is a view illustrating an example of an extended A/D MAC CEformat for supporting up to 32 serving cells.

Since the legacy A/D MAC CE format has seven Ci fields, it may representup to seven serving cells. Accordingly, as the number of serving cellsrises up to 32, all of the serving cells cannot be represented. Thus, afour-byte A/D MAC CE is newly defined. Since the Pcell is always in theactivated state, it is excluded from the A/D MAC CE. Accordingly,information regarding activation or deactivation may be given to a totalof 32 serving cells. There may be various extended A/D MAC CE formatsdepending on the position of the R bit. FIG. 12(a) or 12(b) shows anexample. When the first byte is identical to the legacy A/D MAC CE, itwould have the form shown in FIG. 12(a). Otherwise, when the R bit ispositioned in the last byte stream, it would have the form shown in FIG.12(b). According to the present disclosure, the description is based onFIG. 12(a). Each Ci field corresponds to one SCell. Also, one Ci fieldcorresponds to an SCell denoted with SCellIndex i.

Since the extended A/D MAC CE has a size four times that of the legacyA/D MAC CE, even when the terminal is capable of supporting up to 32serving cells, always using the extended A/D MAC CE would not bepreferable in a signaling overhead point of view. Accordingly, accordingto an embodiment of the present disclosure, whether to use the extendedA/D MAC CE is determined depending on the number of configured SCells.Further, the SCells may be classified in various types. As an example,there may be not only normal SCells, but also PUCCH SCells enablingPUCCH transmission, licensed-assisted access (LAA) SCells usingunlicensed frequency bands (industrial scientific medical (ISM) bands),or Wi-Fi SCells in the LTE Wi-Fi integration technology. According to anembodiment of the present disclosure, it is assumed that activation ordeactivation does not apply to Wi-Fi SCells.

FIG. 13 is a view illustrating a method for selecting a normal orextended A/D MAC CE according to an embodiment of the presentdisclosure.

The terminal 1300 camps on one serving cell (1310). The “camps on” meansthat the terminal 1300 syncs with the base station 1305 is in acommunicable state for basic control information for communication withthe base station on a particular frequency band through the process ofreceiving master information block (MIB) such as physical broadcastchannel (PBCH) and system information block (SIB) such as physicaldownlink shared channel (PDSCH).

The terminal performs an RRC connection configuration process to thebase station 1305 for data communication (1315). The base station sendsa request for capability information to the terminal (1320). Theterminal transmits its capability information to the base station(1325). The capability information may include information as to whetherthe terminal may support up to 32 serving cells which are more than,conventionally, five serving cells. Further, the capability informationmay include capability information as to whether it may support LAA andLTE-Wi-Fi integration. When obtaining the terminal capabilityinformation, the base station reconfigures the RRC connection for theterminal based on the information (1330). The reconfigurationinformation may include configuration information on normal SCell, PUCCHSCell, LAA SCell, and Wi-Fi SCell. The terminal receives an RRCconnection reconfiguration message including the configurationinformation and then identifies configuration information regardingvarious types of SCells. When configured, it configures normal SCell,PUCCH SCell, and LAA SCell and deems the cells as deactivated. Incontrast, it completes the association/authentication procedure for theWi-Fi SCell and deems the Wi-Fi server as activated. The base stationdetermines the A/D MAC CE format to be used to activate or deactivate atleast one SCell for the terminal as per predetermined rules (1335). Thepredetermined rules are as follows.

A first rule: When the number of the remaining SCells other than theWi-Fi SCell is seven or less, the legacy A/D MAC CE format is used.Otherwise, when the number of the remaining SCells exceeds seven, theextended A/D MAC CE format is used.

A second rule: When the highest SCellIndex value of the remaining SCellsother than the Wi-Fi SCell is seven or less, the legacy A/D MAC CEformat is used. Otherwise, when the highest SCellIndex value exceedsseven, the extended A/D MAC CE format is used.

The A/D MAC CE format to be used to activate or deactivate at least oneSCell for the terminal may be determined by applying at least one of thetwo rules.

The two A/D MAC CE formats may have the same or different LCIDs. Whenthe two formats use the same LCID, the terminal is previously aware whattype of A/D MAC CE format is to be received considering the type andnumber of SCells configured therein. When the two formats use differentLCIDs, the terminal may be aware whether the legacy A/D MAC CE format orthe extended A/D MAC CE format directly through the LCIDs. Afterdetermining one format using the above rules, the base station transmitsthe A/D MAC CE to the terminal (1340 and 1345). For example, uponselecting the legacy A/D MAC CE, the base station transmits the legacyA/D MAC CE to the terminal (1340), and upon selecting the extended A/DMAC CE, the base station transmits the extended A/D MAC CE to theterminal (1345).

FIG. 14 is a flowchart illustrating an operation of a base stationaccording to an embodiment of the present disclosure.

The base station performs an RRC connection establishment process withthe terminal for data communication (1400). The base station obtainsterminal capability information from the terminal (1405). The basestation transmits an RRC connection reconfiguration message to theterminal for reconfiguration (1410). The RRC message may includeinformation necessary to configure a plurality of SCells in theterminal. The configuration information may include configurationinformation on normal SCell, PUCCH SCell, LAA SCell, and Wi-Fi SCell.The base station triggers activation or deactivation for at least one ofthe SCells configured in the terminal (1415). The base stationdetermines whether to use the legacy A/D MAC CE or extended A/D MAC CEunder predetermined rules (1420). For example, when the highestSCellIndex value of the remaining SCells other than the Wi-Fi SCell isseven or less, the legacy A/D MAC CE format is used (1425). Otherwise,when the highest SCellIndex value is more than seven, the extendedformat is used (1430).

FIG. 15 is a flowchart illustrating an operation of a terminal accordingto a first embodiment of the present disclosure.

The terminal camps on one serving cell (1500). The terminal performs anRRC connection configuration process with the base station for datacommunication (1505). The terminal transmits its capability informationto the base station (1510). The terminal receives an RRC connectionreconfiguration message from the base station (1515). The RRC messagemay include information necessary to configure a plurality of SCells inthe terminal. The configuration information may include configurationinformation on normal SCell, PUCCH SCell, LAA SCell, and Wi-Fi SCell.The terminal applies the received configuration information andconfigures normal SCell, PUCCH SCell, and LAA SCell, and then deems thecells as deactivated (1520). In contrast, the terminal completes theassociation/authentication procedure for the Wi-Fi SCell and deems theWi-Fi server as activated. The terminal receives the A/D MAC CEindicating whether at least one of the SCells configured in the terminalis activated or deactivated and determines whether the A/D MAC CE is thelegacy A/D MAC CE or the extended A/D MAC CE (1525). When the terminalreceives the legacy A/D MAC CE, the terminal maintains the current state(activated or deactivated state) for the SCells with an SCellIndex valuelarger than seven (1530). For the SCells with an SCellIndex value fromone to seven, the terminal disregards the Ci field corresponding to theWi-Fi SCell and maintains the current state of the Wi-Fi SCell (1535).For the SCells with an SCellIndex value from one to seven, the terminalactivates or deactivates the normal SCell, PUCCH SCell, and LAA SCellaccording to the corresponding Ci field (1540).

When the terminal receives the extended A/D MAC CE, the terminaldisregards the Ci field corresponding to the Wi-Fi SCell and maintainsthe current state (1545). The terminal activates or deactivates thenormal SCell, PUCCH SCell, and LAA SCell according to the Ci fieldscorresponding to thereto (1550).

FIG. 16 is a block diagram illustrating a configuration of a terminalaccording to an embodiment of the present disclosure.

The terminal communicates, e.g., data with a higher layer unit 1605,communicates control messages through a control message processor 1607,and the terminal, upon transmission, multiplexes data through amultiplexer 1603 under the control of the controller 1609 and thentransmits the data through a transmitter, and the terminal, uponreception, receives physical signals through a receiver under thecontrol of the controller 1609 and then demultiplexes the receivedsignals through a demultiplexer 1603 and transfers the signals to thehigher layer unit 1605 or control message processor 1607 according toeach message information.

The transceiver 1613 receives data and a predetermined control signalthrough a forward carrier and transmits data and a predetermined controlsignal through a backward carrier.

According to the present disclosure, when the control message controller1607 receives the A/D MAC CE, it provides the same to the SCellactivation/deactivation processor 1611.

The SCell activation/deactivation processor 1611 maintains the currentstate (activated or deactivated state) for the SCells with an SCellIndexvalue larger than seven if the received A/D MAC CE is the legacy A/D MACCE. The SCell activation/deactivation processor 1611 disregards the Cifield corresponding to the Wi-Fi SCell for the SCells with an SCellIndexvalue from one to seven and maintains the current state of the Wi-FiSCell. Further, the SCell activation/deactivation processor 1611activates or deactivates the normal SCell, PUCCH SCell, and LAA SCellaccording to the corresponding Ci field (1540) among the SCells with anSCellIndex value from one to seven.

When the received A/D MAC CE is the extended A/D MAC CE, the SCellactivation/deactivation processor 1611 disregards the Ci fieldcorresponding to the Wi-Fi SCell and maintains the current state. TheSCell activation/deactivation processor 1611 activates or deactivatesthe normal SCell, PUCCH SCell, and LAA SCell according to the Ci fieldcorresponding thereto.

Meanwhile, radio communication technology has sharply advanced, andaccordingly, communication system techniques have evolved over and over.Among them, the LTE system standardized by the 3GPP standardizationorganization gains more attention as 4th-generation mobile communicationtechnology.

The LTE system has adopted techniques to support various types ofterminals, and the technology for supporting machine type communication(MTC) terminals is among them. MTC terminal refers to, e.g., a machinethat may perform communication on its own (e.g., at a predetermined timeevery month) rather than directly manipulated by a human, such as anelectricity or water meter for billing, and such terminal commonly meansdevices to which access may be attempted with lower priority as in theabove examples. Among MTC terminals, terminals used for such purposes asthose of the meter oftentimes do not require high-capability datatransmission and may have lower transmit power. Further, although havingthe same reception capability, such terminals may be placed in an areawith poor communication environment, such as basement or storage room.This led to the need of putting separate types of terminals having acoverage extension or extended coverage (hereinafter, CE) to address thelower transmit power and lower transmission speed issue. In case an MTCterminal needs broader coverage, a separate additional transmissionmethod (e.g., repetitive transmission) should be applied to all datacommunicated with the terminal using CE mode. For example, the networkbroadcasts system information necessary for the terminal to access. Suchsystem information should be inevitably received by the MTC terminalrequiring broader coverage. Thus, there is a need of broadcasting thesystem information through a method different from those of existingtechnology.

Further, MTC terminals may adopt a narrow frequency band of 1.4 MHz forlower-price supply. Existing LTE frequency bands may be set in variousranges, from 1.4 MHz up to 20 MHz. Generally, a 10 MHz frequency band isprimarily used to increase system capability and data rate. Accordingly,a need exists for a method for serving MTC terminals supporting only 1.4MHz frequency band even in the 10 MHz frequency band.

According to an embodiment of the present disclosure, there are provideda method and apparatus for performing machine-type communication. TheMTC terminal is characterized to support coverage extension and use the1.4 MHz frequency band. According to the present disclosure, a method ofsupporting access of MTC terminal is proposed considering the abovefeatures.

The MTC terminal should be supplied at a lower price, and thus, it ishighly likely to be equipped with a lower-capability receiver. Further,the MTC terminal may be installed in an area where it is difficult forcommon users to access according to purposes of use. This means that itmay be placed out of existing LTE coverage that is configuredconsidering the distribution of common users or track along which theymove. Accordingly, coverage needs to be extended for MTC terminal.Despite the above-enumerated causes, a method for extending coverage isto increasing the rate of successful reception by repeatedlytransmitting the same data. All signals, such as control channel or datachannel, as well as system information broadcast by the base stationwould be repetitively transmitted.

Here, repeating existing system information and channels would be veryinefficient and would not be compatible with normal terminals.Accordingly, there is a need for a separate method for MTC terminalsonly while considering compatibility with normal terminals.

FIG. 17 is a view illustrating a process of obtaining system informationfrom a base station and performing access by a machine-typecommunication device.

The MTC terminal 1700 receives MIB 1710 broadcast from the base station1705. The existing MIB transmits the same information every 10 ms in a40 ms period. That is, after the MIB is received four times in totalwithin the 40 ms period, decoding is attempted. However, the MTCterminal, although repetitively receiving the MIB four times, would behighly likely to fail to decode it. Accordingly, more repeatedtransmission of the MIB is needed within 40 ms. Normal terminals receiveexisting MIB only as they do, and MTC terminals should receiveadditional repeatedly transmitted MIB as well as existing MIB. Theadditional MIBs repeatedly transmitted contain the same information asthe existing MIB.

Further, the bits not used in the existing may be used to support theMIB terminal. The existing MIB contains downlink (DL) system frequencybandwidth, system frame number (SFN), and PHICH configurationinformation. The MIB includes ten bits not used, and they may be usedfor the MTC terminal. The following information may be included usingthe 10 bits.

System Capability Information

an indicator indicating whether the base station may support the MTCterminal may be included. The indicator may be constituted of one or twobits.

In case the indicator is configured of one bit, if the indicator is setto TRUE, it indicates that the base station may support 1.4 MHz of theCE of the MTC terminal.

In case the indicator is configured of two bits, one of the bitsindicates whether the base station may support the CE of the MTCterminal, and the other one bit indicates whether the base station maysupport 1.4 MHz of the MTC terminal.

CIF Information

CFI information is information transferred to terminal through originalPCFICH channel. The CFI information indicates how many symbols are usedfor PDCCH. The CFI information allows the terminal to be aware of thetime point from which the PDSCH region starts in one serving frequency.Accordingly, the CFI information should be necessarily obtained by theMTC terminal. However, since the existing PCFICH channel is transmittedin the overall band, the MTC terminal that may receive only the 1.4 MHzband cannot receive the channel. Thus, the CFI information is sent tothe MTC terminal using the bit of the MIB not used, other than theexisting PCFICH channel.

Value Tag

Value tag has an integer value within a range from 0 to X. If the systeminformation provided from the base station varies, the value tag valueis incremented by one. More specifically, the time when the value tagvalue is increased by one comes from the modification period rightbefore the modification period when the varied system information startsto be broadcast with respect to the long-period modification period thatapplies only to the MTC terminal. This is to previously notify the MTCterminal that the system information will be varied in the nextmodification period so that it may prepare for it.

Subband and Frequency Hopping Information

Several 1.4 MHz bands for MTC terminal may be present in the systemfrequency band. Here, the MTC terminal may use the plurality of 1.4 MHzbands while hopping over time. Accordingly, the number of subbands beingused in the cell and hopping pattern information of each subband areprovided. Additionally, there may also be included subband informationwhere SIB y is broadcast to provide system information necessary for theMTC terminal. Or, it may also be defined that SIB y is transmitted inthe subband including a central carrier frequency in a predeterminedsubband, e.g., downlink frequency band, implicitly or in case nosignaling is made.

Configuration Information and Scheduling Information of MTC Sib

include configuration information or scheduling information of SIBrequired for the MTC terminal.

The configuration information means SI-window, SIB periodicity,sib-MappingInfo, and Modification period as included in existing SIB1.The configuration information is not configuration information forexisting SIB but configuration information for the SIB for MTC terminal.Further, scheduling information of SIB for the MTC terminal may also beincluded. According to embodiments described below, it may be includedin the MIB or not.

Scheduling Information on MTC Enhanced Physical Downlink Control Channel(EPDCCH)

includes scheduling information of MTC EPDCCH including the schedulinginformation of SIB necessary for MTC terminal. MTC EPDCCH means EPDCCHfor MTC terminal. The MTC terminal may receive only 1.4 MHz band, andthus, cannot receive existing PDCCH in the cell using a downlink systemfrequency band larger than that. Accordingly, EPDCCH instead of PDCCHshould come in use.

MTC EPDCCH Repetitive Transmission Information

To support CE, the number of times of repetitive transmission of MTCEPDCCH is included.

Physical random access channel (PRACH) Repetitive Transmission andConfiguration Information

includes repetitive transmission information upon PRACH operation. Forexample, the terminal determines the number of times of repetitivetransmission of preamble based on the information. It has three types ofPRACH repetition levels, and the number of times of repetitivetransmission is mapped to each level. The MTC terminal belongs to one ofthe levels as per a predetermined rule and performs repetitivetransmission as many as the number of times defined according to thelevel it belongs. PRACH radio resource information is also included forthe MTC terminal per subband.

MTC SIB Repetitive Transmission Information

includes the number of times of repetitive transmission of SIB for MTC.To support CE, MTC SIB also need be included. The MTC terminal attemptsdecoding by receiving as many as the number of times indicated in theinformation.

Pathloss Offset Information

The MTC terminal determines the number of times of repetitivetransmission according to a predetermined rule. Here, it may use apathloss difference between downlink and uplink as per a rule. The basestation provides the difference value through MIB.

According to an embodiment of the present disclosure, at least one ofthe above-enumerated information items is included. For example, amongthe mentioned information, the system capability information, CFI, andvalue tag information only may be included in the existing MIB, whilethe remaining information may be included in the SIB for MTC. The systeminformation that is not included in the MIB but is necessary for MTCterminal may be included in a new SIB x 1715 for MTC. SIB x includesscheduling information of SIB including common system information forMTC and information not included in the MIB among the above enumeratedinformation items. SIB x is transmitted through a predetermined radioresource without the need of first reading the EPDCCH. Or, the EPDCCHhaving the scheduling information of SIB x may have been previouslydetermined. The reason why transmission is made through thepredetermined radio resource is to minimize waste of radio resources totransmit scheduling information of SIB x or EPDCCH. However, SIB x isnot scheduled, and thus, it is not preferable to design to include toomuch information. Accordingly, it is required to include onlyinformation that is not included in the MIB but is determined to benecessary. For example, SIB x includes the scheduling information ofEPDCCH indicating SIB y including the system information for normal MTC,and the MTC terminal sequentially receives SIB y 1720 using theinformation. SIB y is a new MTC-dedicated SIB including only informationnecessary for MTC among the information included in existing SIB1 toSIB17. Generally, SIB1 to SIB5, SIB14 information are required for MTCterminal as well, and the information not needed among them or permittedsize of list may be restricted to reduce the size of SIB y. As theamount of system information increases, the repetitive transmissioncount increases. Accordingly, the size of one SIB needs to be restrictedto reduce excessive repetitive transmission. For example, it may belimited to 300 to 400 bits or to the maximum 1000 bits. Accordingly, incase information necessary for MTC is not small, there may be aplurality of SIB y's. A process of obtaining system information for MTCis described in further detail in the following embodiments.

Through the above process, the MTC terminal having obtained systeminformation attempts random access (1725). The MTC terminal uses a PRACHradio resource for MTC terminal only that is separated from the PRACHradio resource used by normal terminal. This is why the MTC terminal mayuse limited 1.4 MHz band alone. That is, it may be using the frequencyband not including the existing PRACH radio resource. On the other hand,since a number of MTC terminals may be present in one cell, the PRACHradio resource is needed to maintain the rate of successful access bycommon users. The base station may grasp whether the terminal havingtransmitted the preamble is the MTC terminal based on the PRACH radioresource where the preamble has been transmitted. To support CE, the MTCterminal will repetitively transmit the preamble, and the random accessresponse (RAR) 1730 transmitted from the base station is alsorepetitively transmitted. Msg3 may send capability information of theMTC terminal (1735). If a separate PRACH radio resource is operated forthe MTC terminal, there is no need for Msg3 to send the capabilityinformation. The MTC terminal may provide the capability informationregarding the terminal through an RRC process providing the capabilityinformation to the base station (1740).

According to the fifth, sixth, and seventh embodiments, methods foreffectively providing system information to MTC terminal are described.

FIG. 18 is a view illustrating a method of obtaining system informationfrom a base station by a machine-type communication device according toa fifth embodiment of the present disclosure.

The fifth embodiment includes necessary system information and featuresthe existence of new SIB x for MTC terminal transmitted through apredetermined radio resource. SIB x is transmitted through thepredetermined radio resource, and it is unnecessary to previously readEPDCCH. Legacy MIB 1810 is transmitted through the first subframe 1805of each frame 1800 according to the prior art. The legacy MIB having thesame information is transmitted four times in total for 40 ms. Further,to support MTC terminal, additional information may add to the legacyMIB. For example, the additional information includes system capacityinformation or CFI. The MTC terminal may fail to successfully decodewith the legacy MIB transmitted four times for 40 ms. Accordingly,another MIB 1815 including the same information as the MIB isadditionally and repetitively transmitted while avoiding radio resourcestransmitting the legacy MIB within 40 ms. The additionally repeatedlytransmitted MIB 1815 is transmitted through a predetermined radioresource like the legacy MIB, and it is transmitted in the middle 1.4MHz frequency of the frequency band, but temporally uses other radioresource and thus does not overlap the legacy MIB. Further, the MIB 1815is not transmitted through uplink subframe or MBSFN subframe in TDD. TheMTC terminal having obtained the system information transmitted from theMIB within 40 ms may use the CIF information included in the MIB tograsp the position that PDSCH starts in the subframe. The MTC terminalreceives SIB x 1820 transmitted through a predetermined radio resourcein the PDSCH region. SIB x also includes system information necessaryfor the MTC terminal. That is, SIB y may include at least one of thefollowing pieces of information.

-   -   scheduling information of MTC EPDCCH 1825    -   MTC EPDCCH repetitive transmission information    -   Cell barring information on MTC terminal

includes legacy access class barring (ACB), service specific accesscontrol (SSAC), and extended access barring (EAB) information. Or mayhave simplified version information regarding the ACB, SSAC, EABinformation. Additionally includes information on MTC emergency call.The one bit indicator for the MTC emergency call is used to indicatewhether the cell permits the MTC terminal emergency call.

-   -   Value tag

same as above description

-   -   Subband and frequency hopping information

same as above description

-   -   PRACH repetitive transmission and configuration information

same as above description

-   -   Pathloss offset information

same as above description

The MTC EPDCCH contains scheduling information of other SIB. SIB x isalso repeatedly transmitted over several subframes to support CE. TheMTC terminal having succeeded in decoding information of SIB x receivesMTC EPDCCH using the scheduling information of EPDCCH included in SIB x.MTC EPDCCH is also repeatedly transmitted to support CE. The MTC EPDCCHcontains scheduling information of SIB y including general systeminformation necessary for MTC terminal. The MTC terminal receives SIB yrepeatedly transmitted using the scheduling information of SIB y fromthe EPDCCH. SIB y, as described above, includes general systeminformation necessary to support MTC terminal.

FIG. 19 is a view illustrating a method of obtaining system informationfrom a base station by a machine-type communication device according toa sixth embodiment of the present disclosure.

The sixth embodiment of the present disclosure features that EPDCCHindicating scheduling information of new SIB y for MTC terminalincluding necessary or general system information is transmitted at apredefined radio resource position. Legacy MIB 1910 is transmittedthrough the first subframe 1905 of each frame 1900 according to theprior art. The legacy MIB having the same information is transmittedfour times in total for 40 ms. Further, to support the MTC terminal,system capacity information, CFI, or Mapping information on repeatedtransmission of MTC EPDCCH is additionally included in the MIB. The MTCterminal may fail to successfully decode with the legacy MIB transmittedfour times for 40 ms. Accordingly, another MIB 1915 including the sameinformation as the MIB is additionally and repetitively transmittedwhile avoiding radio resources transmitting the legacy MIB within 40 ms.The additionally repeatedly transmitted MIB 1915 is transmitted througha predetermined radio resource like the legacy MIB, and it istransmitted in the middle 1.4 MHz frequency of the frequency band, buttemporally uses other radio resource and thus does not overlap thelegacy MIB. Further, the MIB 1915 is not transmitted through uplinksubframe or MBSFN subframe in TDD. The MTC terminal having obtained thesystem information transmitted from the MIB within 40 ms may use the CIFinformation included in the MIB to grasp the position that PDSCH startsin the subframe. The MTC terminal receives MTC EPDCCH 1920 transmittedthrough a predetermined radio resource in the PDSCH region.

FIG. 20 is a view illustrating an MTC EPDCCH transmitted through apredetermined radio resource according to an embodiment of the presentdisclosure.

FIG. 20 illustrates one subframe 2000 including a plurality of subbands2015, 2020, and 2025 for MTC terminal. A few first slots in the subframeare an existing PDCCH region 2005. The PDCCH information of PDCCH regioncannot read MTC terminals. This is why PDCCH should be transmitted overthe overall downlink frequency band to obtain the PDCCH information. Toreplace this, an MTC EPDCCH is required which may function as existingPDCCH in the 1.4 MHz band. The position of the MTC EPDCCH radio resourcemay be previously determined or set through MIB or SIB. If it ispredetermined, scheduling of MTC EPDCCH radio resource is not needed,and thus, signaling overhead may be reduced. For example, a few slotssubsequent to the existing PDCCH region are previously defined as radioresource region of MTC EPDCCH 2010. The frequency bandwidth where MTCEPDCCH is transmitted is the same as the subband width, 1.4 MHz. Theinformation provided by the MTC EPDCCH becomes the schedulinginformation of MTC terminal using the subband where the MTC EPDCCH istransmitted. Or, through additional scheduling, it may be used toprovide scheduling information of MTC terminal using other subband. SIBy may be transmitted only through a predetermined particular subband, orinformation on the subband where SIB y is broadcast may be obtained fromMIB. The MTC terminal attempts to receive MTC EPDCCH transmitted throughthe predetermined radio resource in the subband where SIB y isbroadcast. MTC EPDCCH is also repeatedly transmitted over severalsubframes to support CE. The MTC EPDCCH contains scheduling informationof SIB y 1925 for MTC terminal. The MTC terminal having succeeded indecoding MTC EPDCCH information uses the scheduling information of SIB yincluded in the MTC EPDCCH to receive SIB y. SIB y is also repeatedlytransmitted to support CE. SIB y contains general or necessary systeminformation for the MTC terminal. SIB y has at least one of thefollowing pieces of information.

-   -   Cell barring information on MTC terminal

same as above description

-   -   Value tag

same as above description

-   -   Subband and frequency hopping information

same as above description

-   -   PRACH repetitive transmission and configuration information

same as above description

-   -   Pathloss offset information

same as above description

-   -   System information or part included in SIB1 to SIB5, SIB14

same as above description

FIG. 21 is a view illustrating a method of obtaining system informationfrom a base station by a machine-type communication device according toa seventh embodiment of the present disclosure.

The seventh embodiment of the present disclosure features that new SIB yfor MTC terminal including necessary or general system information istransmitted at a predefined fixed radio resource position. Legacy MIB2110 is transmitted through the first subframe 2105 of each frame 2100according to the prior art. The legacy MIB having the same informationis transmitted four times in total for 40 ms. Further, to support theMTC terminal, system capacity information, CFI, or information onrepeated transmission of SIB y is additionally included in the MIB. TheMTC terminal may fail to successfully decode with the legacy MIBtransmitted four times for 40 ms. Accordingly, another MIB 2115including the same information as the MIB is additionally andrepetitively transmitted while avoiding radio resources transmitting thelegacy MIB within 40 ms. The additionally repeatedly transmitted MIB2115 is transmitted through a predetermined radio resource like thelegacy MIB, and it is transmitted in the middle 1.4 MHz frequency of thefrequency band, but temporally uses other radio resource and thus doesnot overlap the legacy MIB. Further, the MIB 2115 is not transmittedthrough uplink subframe or MBSFN subframe in TDD. The MTC terminalhaving obtained the system information transmitted from the MIB within40 ms may use the CIF information included in the MIB to grasp theposition that PDSCH starts in the subframe. The MTC terminal receivesSIB y 2120 transmitted through a predetermined radio resource in thePDSCH region.

SIB y is also repeatedly transmitted over several subframes to supportCE. SIB y contains general or necessary system information for the MTCterminal. SIB y has at least one of the following pieces of information.

-   -   Cell barring information on MTC terminal

same as above description

-   -   Value tag

same as above description

-   -   Subband and frequency hopping information

same as above description

-   -   PRACH repetitive transmission and configuration information

same as above description

-   -   Pathloss offset information

same as above description

-   -   System information or part included in SIB1 to SIB5, SIB14

same as above description

System information for MTC terminal may be updated as well. Accordingly,the base station should inform the MTC terminal that system informationhas been updated so that the MTC terminal may obtain new systeminformation. The existing process of updating system information is notproper for MTC terminal. The existing process of updating systeminformation is performed with respect to modification period. That is,the base station broadcasts updated system information at the time thatmodification period is about to start. The base station informs theterminal that the updated system information is to be transmitted in thenext modification period in the previous modification period through apaging message. The MTC terminal requiring CE mode should repeatedlyreceive the information to receive the information transmitted from thebase station. This means that it takes a significant time tosuccessfully decode particular information. The existing modificationperiod cannot exceed up to 10.24 seconds. The MTC terminal in the CEmode should repeatedly receive this to receive the paging message.Accordingly, the MTC terminal would be highly likely to fail tosuccessfully decode the paging message informing the update of thesystem information within one cycle of the modification period.

According to eighth and ninth embodiments of the present disclosure, amethod of updating system information for MTC terminal is now described.

FIG. 22 is a view illustrating a method of updating system informationaccording to an eighth embodiment of the present disclosure.

In the eighth embodiment of the present disclosure, separately definedis a modification period 2200 having a very long period for MTC terminalunlike the existing modification period. The existing modificationperiod cannot be set to be longer than the existing SFN period.Accordingly, the SFN period should be definitely determined to set amodification period that is longer than, at least, the SFN period, forthe MTC terminal. The determined SFN period applies only to MTCterminal, and normal terminals need not obtain that. Additional bitsalong with the SFN information provided in the existing MIB are definedto provide an SFN having an extended period applying only to MTCterminal. The added SFN bit information is included in MIB or SIBx orSIB y. The modification period value is provided to the MTC terminalusing MIB, SIBx or SIB y for MTC mentioned above. If updated systeminformation is broadcast in modification period n+1 2205, the basestation transmits a paging message 2215 to the MTC terminal to indicatethat system information is to be updated in the next modification periodin the previous modification period n 2200. The MTC terminal receivesEPDCCH repeatedly transmitted in modification period n 2200. The EPDCCHincludes, a repetition count of paging message, radio resourceinformation where the paging message is transmitted, as well as thepaging RNTI (P-RNTI). If the EPDCCH contains the P-RNTI, the pagingmessage 2215 is received in the radio resource of the paging messageindicated by the EPDCCH. If the paging message contains an indicatorindicating that system information is to be updated in the nextmodification period, the MTC terminal receives the updated systeminformation 2220 in the next modification period. The MTC terminalperforms an operation of receiving paging message at least once everymodification period.

FIG. 23 is a view illustrating a method of updating system informationaccording to a ninth embodiment of the present disclosure.

Like the eighth embodiment, the ninth embodiment applies a modificationperiod having a very long period for MTC terminal. The ninth embodimentof the present disclosure features using one IE, i.e., value tag, inMIB, SIB x, SIB y, or EPDCCH to indicate that system information is tobe updated in the next modification period. The value tag has an integervalue in a range from 0 to X. Whenever system information is updated, itis incremented by one. The time when the value tag value is incrementedby one is the modification period 2305 when updated system informationstarts to be broadcast or its previous modification period 2300. The MTCterminal decodes MIB, SIB or EPDCCH at least once each modificationperiod and then compares the value tag value with a value tag value itstores. If the two values differ, the time when the updated systeminformation is obtained is varied depending on the modification periodwhen the value tag value is updated. That is, if the time when the valuetag value is increased by one is the modification period 2305 whenupdated system information starts to be broadcast, the MTC terminalperforms an operation of receiving the newly updated system informationimmediately when recognizing that the newly obtained value tag value isdifferent from the one it stores. Otherwise, if the time when the valuetag value is increased by one is the modification period 2300 rightprior to the modification period 2305 when updated system informationstarts to be broadcast, the MTC terminal performs an operation ofreceiving the newly updated system information when the nextmodification period arrives after it recognizes that the newly obtainedvalue tag differs from the one it stores. If the MTC terminal is backoff the service shade area, it decodes MIB, SIB x, and SIB y or EPDCCHto obtain value tag information. Then, it compares it with the value tagvalue stored last, and if different, immediately performs an operationof receiving the updated system information. Then, it compares it withthe value tag value stored last, and if the same, uses the existingsystem information as obtained.

In a variation to the ninth embodiment of the present disclosure, theMTC terminal identifies value tag of MIB, SIB x, SIB y, or EPDCCH beforeattempting to access. It compares it with the value tag value storedlast, and if different, immediately performs an operation of receivingthe updated system information. The MTC terminal abstains fromidentifying value tag of MIB, SIB x, SIB y, or EPDCCH if it does notattempt to access. The modified method is proper for MTC terminal thattransmits delay tolerant data and infrequently attempts to access. Thatis, for MTC terminal attempting access once or twice per month, checkingas to whether system information has been updated every modificationperiod is unnecessary. This is why it would not cause any trouble toobtain the latest most precise system information before access isattempted. Further, an operation of first obtaining MIB or SIB beforeaccess means that delay occurs until access is successfully set.However, when requesting a delay tolerant service, such delay would notbe a major issue.

According to the present disclosure, there is proposed a process ofperforming RACH for MTC terminal in CE mode. Prior to describing thepresent disclosure, the prior art is briefly described.

FIG. 24 is a view illustrating an existing RACH process and a method ofcomputing RA-RNTI.

The terminal requiring access transmits a preamble in the PRACH radioresource 2400. Although the size of radio resource available may varydepending on whether FDD/TDD or mask, but the overall PRACH radioresource is divided into time slot and frequency slot. An RA-RNTI valueis determined depending on the position that the preamble transmissionis started. The following is an equation used to calculate RA-RNTI.

RA-RNTI=1+t_id+10*f_id  [Equation 1]

For example, if terminal 1 transmits a preamble in a particular radioresource location 2405, one random access RNTI (RA-RNTI) 2420 iscalculated considering the corresponding radio resource location andcorresponding time slot (t_id) and frequency slot (f_id). Threesubframes after transmitting the preamble, RAR window 2435 starts. RARwindow is set to 2 ms to, up to, 10 ms. The terminal monitors PDCCHwithin the RAR window and identifies whether the PDCCH has an RA-RNTIcalculated from the position of transmission of the preamble. If thereis the RA-RNTI, an RAR message is received from corresponding schedulinginformation. The MTC terminal that is in the CE mode needs torepetitively transmit preambles and should repetitively receive RARmessages. Accordingly, the existing random access process is not properfor MTC terminal.

FIG. 25 is a view illustrating an RACH process according to anembodiment of the present disclosure.

According to an embodiment of the present disclosure, a process ofperforming RACH is proposed considering repetitive transmission ofpreambles and RAR messages. The MTC terminal repetitively transmitspreambles in the same time slot (t_id) and frequency slot (f_id) foreach and every PRACH radio resource 2505 repeatedly allocated. Further,it uses the same preamble sequence (the same preamble ID) for eachrepetitive transmission. The reason for using the same time slot (t_id)and frequency slot (f_id) is to make one RA-RNTI correspond to each MTCterminal attempting access. Further, the reason for using the samepreamble sequence is to allow the base station to do soft combining onthe preambles repeatedly received. For example, if terminal 1 transmitsa preamble in a particular radio resource 2510, it transmits the samepreamble in the same radio resource location upon next repetitivetransmission. In such case, the RA-RATI of terminal 1 is supposed tohave one value 2525 without confusion. The PRACH radio resource for MTCterminal is separated from the PRACH radio resource used by the normalterminal. The PRACH radio resource information and repetitivetransmission count of preamble used by the MTC terminal are providedfrom the MIB, SIB x or SIB y. If the predetermined repetitivetransmission period of preamble is terminated, the MTC terminaldetermines whether there is the random access-radio network temporaryidentity (RA-RNTI)calculated by reflecting the location of the radioresource where the preamble has been transmitted from the EPDCCH 2540.If the transmission of the last preamble is ended, there is a need fortime to combine and process the preambles repeatedly received by thebase station and configure EPDCCH (and RAR message). Accordingly, npredetermined subframes 2550 after the last preamble has beentransmitted, an operation of receiving the MTC EPDCCH is performed. Ifthe period of repeated reception of EPDCCH as set is terminated, and theEPDCCH successfully decoded includes the RA-RNTI calculated by itself,the MTC terminal receives the RAR message 2545 using the schedulinginformation indicated by the RA-RNTI. To support the MTC terminal thatis in the CE mode, the RAR message is also repeatedly received. The RARwindow is also extended due to the RAR message and EPDCCH repeatedlyreceived. The extended RAR window value may be included in the MIB, SIBx or SIB y that may be then provided to the MTC terminal. Or, the MTCterminal may calculate the RAR window based on the information regardingthe repetitive transmission count of RAR message and the EPDCCH includedin the MIB, SIB x or SIB y. If the EPDCCH received by the MTC terminaldoes not contain the RA-RNTI calculated by itself or the RAR messagereceived does not include the preamble ID sent by itself, it is deemedfailure to access. As in the prior art, if backoff information has beenreceived from the base station, access may be reattempted after waitingfor the backoff time.

FIG. 26 is a view illustrating a method of selecting a subband to beused for access by each machine-type communication device according toan embodiment of the present disclosure.

The MTC terminal uses a limited frequency band of 1.4 MHz. Further, the1.4 MHz band used may be subject to frequency hopping. Accordingly,existing PRACH radio resources that are provided for use of normalterminals might not be used. That is, in case the 1.4 MHz band does notinclude the existing PRACH radio resource, the MTC terminal cannot usethe existing PRACH radio resource. Further, the base station need graspthe type of terminal attempting access from the accessing stage. Forexample, for MTC terminal supportive of CE mode, preambles transmittedfrom the terminal should be subject to soft combining. However, there isno way for the MTC terminal to be able to report its capacity to thebase station before access. Accordingly, there is needed a methodcapable of informing the type of terminal transmitting the preamble atthe stage of transmitting preambles. For the reasons mentioned above,the present disclosure features allocating a separate PRACH radioresource for MTC terminal. Further, a plurality of 1.4 MHz frequenciesin the downlink frequency band 2600 can use. Here, each MTC terminal2605, 2610, and 2615 should determine which subband of PRACH radioresource is to be used. To distribute the load of each subband, each MTCterminal may randomly select one subband. Or, one subband may also beselected using UE_ID (=IMSI mod 4092) or Access Class (AC). That is,UE_ID mod N or AC mod N. Proposed is a method of selecting a subbandaccording to information on necessary PRACH repetitive transmissioncount (PRACH repetition level) according to the present disclosure. TheMTC terminal determines the PRACH repetition level it belongs by apredetermined rule. There are three PRACH repetition levels in total,and the number of times of repetitive transmission of preamble or RARmessage is determined for each level. The PRACH repetitive transmissioncount corresponding to the repetition level is predetermined or setthrough the MIB, SIB x or SIB y. The predetermined rule is as follows.

-   -   Option 1: Determine PRACH repetition level considering the        number of times of PBCH reception or CRS signal quality until        PBCH is successfully decoded. For example,

PBCH reception count<threshold 1→PRACH repetition level 1

threshold 1≦PBCH reception count<threshold 2→PRACH repetition level 2

threshold 2≦PBCH reception count→PRACH repetition level 3

Here, it is assumed that as PRACH repetition level decreases, thecorresponding repetitive transmission count decreases.

Or

common reference signal (CRS) signal quality (e.g., reference signalreceived power (RSRP))<threshold A→PRACH repetition level 3

threshold A≦CRS signal quality<threshold B→PRACH repetition level 2

threshold B≦CRS signal quality→PRACH repetition level 1

The thresholds are predetermined or set through MIB, SIB x or SIB y.

-   -   Option 2: Reflect signal quality of downlink channels only.        Option 2 determines PRACH repetition level considering PRACH        required power as well as the count of PBCH reception. For        example, when determining preamble transmission power, it is        calculated reflecting the pathloss difference between downlink        and uplink. PRACH repetition level is determined based on the        calculated transmission power.

PRACH transmit power<threshold X→PRACH repetition level 1

threshold X≦PRACH transmit power<threshold Y→PRACH repetition level 2

threshold Y≦PRACH transmit power→PRACH repetition level 3

The pathloss difference between downlink and uplink and thresholds arepredetermined or set through MIB, SIB x or SIB y.

-   -   Option 3: The PRACH repetition level is determined in a trial        and error manner. The MTC terminal first performs RACH process        at the lowest PRACH repetition level. Upon failure, it increases        the PRACH repetition level.

According to an embodiment of the present disclosure, one of theabove-described methods is used and the MTC terminal having determinedthe PRACH repetition level performs RACH process using one of thesubbands corresponding to the level. According to the presentdisclosure, the subbands are mapped to one of the levels. The mappinginformation is set through the MIB, SIB x or SIB y. The reason formapping is to differentiate the repetitive transmission count necessaryfor each terminal with subbands on the base station position. The basestation cannot be aware which PRACH repetition level each MTC terminalhas chosen. Further, the level applied to one terminal may be variedover time. In particular, for moving MTC terminals, the level would befrequently varied. However, the base station should be aware of thelevel to perform PRACH operation. That is, it may be aware of the countof preambles repetitively received according to the level and may derivethe count of repetitive transmission of EPDCCH or RAR message. To thatend, mapping each subband with the level would allow the base station toeasily grasp the level of the terminal depending on the subband throughwhich the MTC terminal transmits preamble.

The lower frequency, the better radio channel characteristic ispresented. Thus, a higher PRACH repetition level (level requiring morecount of repetitive transmission) may be allocated to a subband using alower frequency band.

Upon reselection among the cells of other frequency with the samepriority or with the same frequency in legacy LTE technology,R-criterion is used as follows. Rs applies to serving cell, and Rnapplies to neighbor cell. The terminal compares the calculated valuesand performs reselection through the cell with the highest (rank) value.

TABLE 13 R_(s) = Q_(meas, s) + Q_(Hyst) − Qoffset_(temp) R_(n) =Q_(meas, n) − Qoffset − Qoffset_(temp)

Here, the parameters used in the above equations are defined as follows.

TABLE 14 Q_(meas) RSRP measurement quantity used in cell reselections.Qoffset For intra-frequency, Equals to Qoffset_(s, n), if Qoffset_(s, n)is valid, otherwise this equals to zero. For inter-frequency, Equals toQoffset_(s, n) plus Qoffset_(frequency), if Qoffset_(s, n) is valid,otherwise this equals to Qoffset_(frequency). Qoffset_(temp) Offsettemporarily

According to the prior art, cell to be reselected is determined merelybased on the above-described rank value. However, whether to support thefeature should also be taken into account for the wireless network wherebase stations that support MTC CE or RBW and base stations that do notco-exist. For example, assuming that there are a cell having the largestrank value but unable to support CE mode and a cell having a rank valuesmaller than the cell but able to support CE mode, the latter cell wouldbe better for MTC terminal that is under poor cell environments butsupportive of CE mode. On the other hand, the cell unable to supportRBW, despite having the largest rank value, is never useful for the MTCterminal supportive only of the 1.4 MHz band.

Unlike the prior art where only rank values are compared, whether cellssupport CE or RBW is also considered to reselect cell according to thepresent disclosure. According to the present disclosure, the rank valuesof cells considered like in the prior art are derived. The MTC terminalsupportive only of 1.4 MHz frequency band excludes cells unable tosupport that regardless of rank value. Further, it may excluderegardless of rank values depending on the measured signal quality andwhether a particular cell supports CE.

FIG. 27 is a view illustrating an operation of a terminal reselecting aproper cell when reselecting a cell among cells belonging to a frequencywith the same priority or the same frequency according to the presentdisclosure.

The terminal discovers a cell having the largest rank value usingexisting R-Criterion equation (2700). The terminal determines whether itsupports only 1.4 MHz reuse bandwidth (“RBW”) (2705). If supporting, theterminal identifies whether the cell having the largest rank valuesupports RBW (2710). The terminal determines whether to support (2715).If not supporting, the terminal excludes the considered cell fromreselection candidates and selects a cell having the next largest rankvalue and then repeats the operations (2725). If supporting, theterminal identifies whether the considered cell is supportive of CE mode(2720). The terminal determines whether to support (2730). If notsupportive, the terminal determines whether the measured channel qualityis good enough to allow it to operate in the normal mode not in the CEmode (2740). If the channel quality requires CE mode, the terminalexcludes the considered cell from the reselection candidates and selects(2725) a cell having he second largest rank value and goes back tooperation 2710. If supportive, the terminal determines whether toconnect to the cell in the normal mode or in the CE mode considering thecurrent channel quality (2735). The terminal determines whether it isconnected in a normal mode or CE mode (2745). If connected in the CEmode, the terminal performs cell reselection in the CE mode (2750). TheMTC terminal, if requiring access, will attempt to access in the CEmode. Otherwise, if connected in the normal mode, the terminal performscell reselection in the normal mode (2755). The MTC terminal, ifrequiring access, will attempt to access in the normal mode. The MTCterminal continues to perform cell measurement and repeats theabove-described operations to perform reselection in the optimal cell.

There are two types of procedures for random access, and the firstprocedure is contention based, and the other procedure is non-contentionbased.

In the contention based procedure, the preamble is randomly selected bythe terminal. However, in the case of the non-contention basedprocedure, the preamble to be used by the terminal is indicated by thenetwork using dedicated signaling means. The preamble is reserved by thebase station (a network entity) for the corresponding terminal. Acontention based random access procedure is described in detail withreference to FIG. 28.

FIG. 28 is a flowchart illustrating a contention-based random accessprocedure used in an LTE system.

The terminal 2801 performs random access by conducting the followingprocedure upon initial access to the base station, re-access, handover,or in other various situations requiring random access.

First, the terminal 2801 transmits a random access preamble through aphysical channel for random access for accessing the base station 2803(2811). The preamble may be one randomly selected by the terminal or aparticular preamble designated by the base station.

Here, the random access preamble is included in Msg1, and the Msg1message is transmitted from the terminal to the base station. The randomaccess preamble may be any one of the 64 available preamble sequencesassociated with each cell.

When the base station receives the random access preamble, the basestation transmits an RAR message (Msg2) therefor to the terminal (2813).The RAR message contains the identifier information on the preamble usedin operation 2801, uplink transmission timing correction information,uplink resource allocation information to be used in operation 2815, andtemporary terminal identifier information.

When receiving the RAR message, the terminal transmits differentmessages depending on the above-described purposes in the resourceallocated to the RAR message (2815). For example, in case of initialaccess, a message of radio resource control (RRC) layer, i.e.,RRCConnectionRequest, is transmitted, and in case of re-access, aRRCConnectionReestablishmentRequest message is transmitted, and in caseof handover, a RRCConnectionReconfigurationComplete message istransmitted.

Thereafter, in case of initial access or reaccess, the base stationre-transmits the message received in operation 2815 to the terminal asUE Contention Resolution Identity MAC CE message (2817) to inform theterminal that random access procedure has succeeded.

FIG. 29 is a view illustrating a frame structure according to anembodiment of the present disclosure.

Referring to FIG. 29, the vertical axis denotes the frequency, and thehorizontal axis denotes the time. The downlink 2999 frame is used totransmit a signal from the base station to the terminal, and the uplink2935 frame is used to transmit from the terminal to the base station.FIG. 29 illustrates an example in which there are N independent bandsavailable by a narrowband MTC terminal on downlink and uplink. First,there is a separate subband for transmitting basic information by whichnarrowband MTC terminal may have initial access (2907). Through thesubband, information necessary for terminals in the cell to performbasic operations, such as MIB and SIB, is transmitted to transmitinformation regarding whether the corresponding cell supports thenarrowband MTC terminal and information regarding the subbands 2901,2903, 2905, 2911, 2913, and 2915 where the narrowband MTC terminaloperates.

Meanwhile, the subbands may be provided in pairs. For example, there maybe downlink 2901 and uplink 2911 corresponding to subband 1, downlink2903 and uplink 2913 corresponding to subband 2, and downlink 2905 anduplink 2915 corresponding to subband N.

It is assumed in FIG. 29 that there is PRACH 2927 for random access peruplink of each subband. That is, if the narrowband MTC terminal selectsone of the subbands provided by the base station, it may presumptivelyperform all the operations within the corresponding subband.

FIG. 30 is a flowchart illustrating a message flow of a random accessprocedure of an MTC terminal as proposed on the frame structuredescribed in connection with FIG. 29 according to a tenth embodiment ofthe present disclosure.

The terminal 3001 supporting only narrowband frequency first checks ifthe base station supports the terminal in order to access the basestation 3003 (3011). Although the terminal supporting only narrowbandfrequency as described above is denoted MTC terminal for ease, thepresent disclosure is not limited to MTC, and it may refer to all typesof terminals supporting only narrowband frequency. In order to informthat the base station supports MTC terminal, according to the presentdisclosure, it is proposed to add a predetermined indicator to MIB, andin case the predetermined indicator is included, the terminal mayidentify that the base station transmitting the MIB supports the MTCterminal and may continue to perform access procedure. In case the basestation does not support the MTC terminal, the terminal determines thatit cannot access the base station and thus the base station is blockedand attempts to access other base station with the same frequency orcell/base station with other frequency.

Thereafter, the terminal receives system information such as SIB1 3013or SIB2 3015 to receive PRACH information and MTC subbands (2901, 2903,2905, 2911, 2913, and 2915 of FIG. 29) information of the current basestation. Further, it may additionally transmit an indicator indicatingwhether access to the MTC subband has been blocked in SIB1 or SIB2(3015). This is for preventing congestion in a particular MTC subband.

When receiving this, the terminal determines the MTC subband at whichthe terminal is to operate and varies the downlink and uplinkfrequencies with the selected MTC subband (3017). In this example, it isassumed that the terminal has selected subband 2 (2903 and 2913 of FIG.29). As described above in connection with FIG. 29, the scenarioaccording to this embodiment assumes that a separate PRACH is presentfor each subband.

It should be noted that upon randomly selecting a subband in operation3017, e.g., RSRP strength may be considered.

Having varied the frequency with the selected subband in operation 3017,the terminal selects preamble for transmission (3019) and transmits theselected preamble (3031). The transmitted preamble may be the same asexisting one defined in LTE system, or may be a preamble additionallydefined for MTC terminal. In case one same preamble is transmitted, ifthe PRACH is shared with other terminals than the MTC terminal, it mayadditionally receive a preamble identifier group used by the MTCterminal from SIB2 and select one preamble of the group and transmit it.

Having received the preamble, the base station transmits a responsemessage thereto, RAR message (3033), and when receiving the RAR message,the terminal transmits Msg3 according to the information included in theRAR message, as described above in connection with FIG. 28 (3035). Incase the terminal shares the PRACH with the normal terminal in operation3031 and transmits one same preamble, when transmitting Msg3, it mayinclude a separate uplink logical channel identifier in the header andtransmit it. The uplink logical channel identifier used is proposed touse one in a range from 0b01011 to 0b11000.

Having succeeded in random access according to the above procedure, theterminal, before until shifting to idle mode (RRC_IDLE state) in thefuture, performs random access on the MTC subband it currently operatesto communicate with the base station when it requires random accessoperation (3041).

FIG. 31 is a flowchart illustrating an operation of a terminal to whichthe tenth embodiment of the random access procedure of the MTC terminalapplies according to an embodiment of the present disclosure.

Referring to FIG. 31, the MTC terminal in RRC_IDLE mode selects a cellthrough cell selection or cell reselection process (3101) and syncs withthe selected cell and receives MIB information (3103). According to thepresent disclosure, in order to inform whether the base station supportsMTC terminal, it is proposed to add a predetermined indicator to theMIB, and in case the predetermined indicator is added (3105), theterminal may continue to perform access procedure by identifying thatthe base station transmitting the MIB supports the MTC terminal.However, in case the base station does not support MTC terminal, theterminal determines that the corresponding has been blocked and performsa procedure of selecting other cell (3109).

In case it identifies that the base station supports MTC terminal, theterminal additionally receives SIB1 and SIB2 from the base station(3107). SIB1 and SIB2 contains PRACH information on the current basestation and MTC subband ((2901)(2903)(2905)(2911)(2913)(2915) in FIG.29) information, and according to the present disclosure, additionally,an indicator indicating whether access to the MTC subband is blocked maybe transmitted through SIB1 or SIB2. This is for preventing congestionin a particular MTC subband.

According to the information received from SIB1 and SIB2, the terminalselects an unblocked MTC subband (MTC subband 2 2903 or 2913 in FIG. 29)randomly or by a predetermined method utilizing the terminal identifierand varies the operation frequency into the corresponding frequency(3111). Thereafter, as described above in connection with FIG. 28,random access is performed (3113). Having succeeded in random access(3115), the terminal continues to operate on the corresponding MTCsubband, and before until shifting to idle mode (RRC_IDLE state) in thefuture, performs random access on the MTC subband it currently operatesto communicate with the base station when it requires random accessoperation (3117). Upon failure to the random access procedure (3115),the terminal selects or reselects another cell (3131).

FIG. 32 is a view illustrating a frame structure according to anembodiment of the present disclosure.

Referring to FIG. 32, the vertical axis denotes the frequency, and thehorizontal axis denotes the time. There are downlink 3233 used fortransmitting signal from base station to terminal and uplink 3235 usedfor transmitting signal from terminal to base station, and in FIG. 32, Nindependent bands are shown that may be used by narrowband MTC terminalon downlink and uplink. First, there is a separate subband fortransmitting basic information by which narrowband MTC terminal may haveinitial access (3207). Through the subband, information necessary forterminals in the cell to perform basic operations, such as MIB and SIB,is transmitted to transmit information regarding whether thecorresponding cell supports the narrowband MTC terminal and informationregarding the subbands 3201, 3203, 3205, 3211, 3213, 3215, and 3217where the narrowband MTC terminal operates.

Meanwhile, the subbands may be provided in pairs. For example, there maybe downlink 3201 and uplink 3211 corresponding to subband 1, downlink3203 and uplink 3213 corresponding to subband 2, and downlink 3205 anduplink 3215 corresponding to subband N.

Unlike in FIG. 29, in FIG. 32, PRACH is not present per uplink of eachsubband, and it is assumed that a separate subband is provided forrandom access commonly used by narrowband MTC terminals (3217). That is,it is assumed that narrowband MTC terminal, whenever needing randomaccess, shifts its operation frequency to the subband 3217 for randomaccess to transmit random access preamble.

FIG. 33 is a flowchart illustrating a message flow of a random accessprocedure of an MTC terminal as proposed on the frame structuredescribed in connection with FIG. 32 according to an eleventh embodimentof the present disclosure.

The terminal 3301 supporting only narrowband frequency first checks ifthe base station supports the terminal in order to access the basestation 3303. Although the terminal supporting only narrowband frequencyas described above is denoted MTC terminal for ease, the presentdisclosure is not limited to MTC, and it may refer to all types ofterminals supporting only narrowband frequency. In order to inform thatthe base station supports MTC terminal, according to the presentdisclosure, it is proposed to add a predetermined indicator to MIB, andin case the predetermined indicator is included, the terminal mayidentify that the base station transmitting the MIB supports the MTCterminal and may continue to perform access procedure. In case the basestation does not support the MTC terminal, the terminal determines thatit cannot access the base station and thus the base station is blockedand attempts to access other base station with the same frequency orcell/base station with other frequency.

Thereafter, the terminal receives system information such as SIB1 3313or SIB2 3315 to receive PRACH information and MTC subbands (3201, 3203,3205, 3211, 3213, 3215, and 3217 of FIG. 32) information of the currentbase station. Further, it may additionally transmit an indicatorindicating whether access to the MTC subband has been blocked in SIB1 orSIB2 (3215). This is for preventing congestion in a particular MTCsubband.

This embodiment assumes that preamble groups are separated per subband.For example, in case there are 50 available preambles, preambles 1 to 10may be used for MTC subband 1, and preambles 11 to 20 may be used forMTC subband 2, and the numbers are merely an example, and the basestation transmits corresponding information to the terminal using SIB1or SIB2.

Accordingly, the terminal performing initial access selects a particularMTC subband through a predetermined method using the terminal'sidentifier or randomly among the currently unblocked MTC subbands of thebase station and selects one preamble corresponding to the correspondinggroup (3321). In the exemplary figure, it is assumed that MTC subband 2is selected, and accordingly, one preamble belonging to MTC subband 2 isselected. Meanwhile, if not initial access, one of preambles of thegroup corresponding to the corresponding subband is selected accordingto the MTC subband currently operated.

Thereafter, the terminal changes (3323) the uplink transmissionfrequency into subband (3217 in FIG. 32) for random access fortransmission of preamble and transmits the selected preamble (3331).Thereafter, in order to receive a response to the transmitted preamble,i.e., RAR message, the terminal changes (3333) the downlink frequencyinto the downlink subband (3103 in FIG. 31) where the transmittedpreamble belongs and receives the RAR message (3335). The base stationallocates resource corresponding to the uplink (3113 of FIG. 31) of thecorresponding group through the RAR message according to the group wherethe preamble received in operation 3331 is received.

Having received the RAR message, the terminal changes the uplinkoperation frequency into the corresponding MTC subband (3213 in FIG. 32)according to the preamble group transmitted in operation 831 andtransmits Msg3 as described above in connection with FIG. 28 (3339).

Having succeeded in random access according to the above procedure, theterminal, before until shifting to idle mode (RRC_IDLE state) in thefuture, selects the preamble corresponding to the MTC subband currentlyoperated (3321) and performs random access according to theabove-described procedure to communicate with the base station when itrequires random access operation.

FIG. 34 is a flowchart illustrating an operation of a terminal to whichthe eleventh embodiment of the random access procedure of the MTCterminal applies according to an embodiment of the present disclosure.

Referring to FIG. 34, the MTC terminal in RRC_IDLE mode selects a cellthrough cell selection or cell reselection process (3401) and syncs withthe selected cell and receives MIB information (3403). According to thepresent disclosure, in order to inform whether the base station supportsMTC terminal, it is proposed to add a predetermined indicator to theMIB, and in case the predetermined indicator is added (3405), theterminal may continue to perform access procedure by identifying thatthe base station transmitting the MIB supports the MTC terminal.However, in case the base station does not support MTC terminal, theterminal determines that the corresponding has been blocked and performsa procedure of selecting other cell (3409).

In case it identifies that the base station supports MTC terminal, theterminal additionally receives SIB1 and SIB2 from the base station(3407). SIB1 and SIB2 contains PRACH information on the current basestation and MTC subband ((3201)(3203)(3205)(3211)(3213)(3215)(3217) inFIG. 32) information, and according to the present disclosure,additionally, an indicator indicating whether access to the MTC subbandis blocked may be transmitted through SIB1 or SIB2. This is forpreventing congestion in a particular MTC subband.

In case the current random access is initial access or reaccess (3411),the terminal selects a particular MTC subband through a predeterminedmethod using the terminal's identifier or randomly among the currentlyunblocked MTC subbands of the base station according to the informationreceived from SIB1 and SIB2 and selects one preamble corresponding tothe corresponding group (3413). In the exemplary figure, it is assumedthat MTC subband 2 is selected, and accordingly, one preamble belongingto MTC subband 2 is selected. Meanwhile, if not initial access, one ofpreambles of the group corresponding to the corresponding subband isselected according to the MTC subband currently operated (3415).

Thereafter, as described above in connection with FIG. 33, random accessis performed (3417). Having succeeded in random access procedure, theterminal continues to operate on the corresponding MTC subband, andbefore until shifting to idle mode (RRC_IDLE state) in the future,selects the preamble corresponding to the MTC subband currently operated(3415) and performs random access (3417) according to theabove-described procedure to communicate with the base station when itrequires random access operation.

FIG. 35 is a flowchart illustrating a message flow of a random accessprocedure of an MTC terminal as proposed on the frame structuredescribed in connection with FIG. 32 according to a twelfth embodimentof the present disclosure.

The terminal 3501 supporting only narrowband frequency first checks ifthe base station supports the terminal in order to access the basestation 3503. Although the terminal supporting only narrowband frequency(e.g., 1.4 MHz) as described above is denoted MTC terminal for ease, thepresent disclosure is not limited to MTC, and it may refer to all typesof terminals supporting only narrowband frequency. In order to informthat the base station supports MTC terminal, according to the presentdisclosure, it is proposed to add a predetermined indicator to MIB, andin case the predetermined indicator is included, the terminal mayidentify that the base station transmitting the MIB supports the MTCterminal and may continue to perform access procedure. In case the basestation does not support the MTC terminal, the terminal determines thatit cannot access the base station and thus the base station is blockedand attempts to access other base station with the same frequency orcell/base station with other frequency.

Thereafter, the terminal receives system information such as SIB1 3513or SIB2 3515 to receive PRACH information and MTC subbands (3201, 3203,3205, 3211, 3213, 3215, and 3217 of FIG. 32) information of the currentbase station. Meanwhile, unlike in the embodiment described above inconnection with FIG. 33, in this embodiment, it is assumed that there isalso downlink random access subband mapped to uplink (e.g., 3207 in FIG.32). That is, if random access preamble is transmitted through subband3217 of FIG. 32, a response message thereto, RAR message, is transmittedthrough a predetermined downlink subband (e.g., 3207 of FIG. 32), andthe information is also received through SIB1 or SIB2.

Having received the PRACH information and MTC subband information, theterminal changes (3521) uplink and downlink operation frequencies intorandom access subbands (3217 of FIG. 32 and downlink mapped thereto(e.g., 3207 of FIG. 7)), selects any preamble (3523), and transmits theselected preamble through a preamble subband (3217 of FIG. 32) (3531).

Thereafter, it receives the RAR message from predetermined preambledownlink subband (3207 of FIG. 32) (3533). The base station configuresinformation on subband where the terminal is to operate in the future inthe RAR message and transmits the same. According to the configurationinformation, the terminal changes the uplink and downlink operationfrequencies into the subbands as configured above (3535) and transmitsMsg3 as described in connection with FIG. 28 (3537) and operates on thecorresponding MTC subband.

Meanwhile, the terminal having successfully performed random accessaccording to the above procedure, when requiring random access in thefuture, changes operation frequency into the random access subband(3521) and performs random access procedure. As such, in case theterminal is being used liked with the base station rather thanperforming initial access or reaccess, the terminal, when transmittingMsg3 (3537), includes the information on the subband where it used tooperate in the Msg3 and informs the base station. To inform, an MAClayer message called a new MAC CE, may be used to notify the informationon the existing MTC subband used. Thereafter, the terminal changes theoperation frequency into the existing MTC subband used and operates(3539).

FIG. 36 is a flowchart illustrating an operation of a terminal to whichthe twelfth embodiment of the random access procedure of the MTCterminal applies according to an embodiment of the present disclosure.

Referring to FIG. 36, the MTC terminal in RRC_IDLE mode selects a cellthrough cell selection or cell reselection process (3601) and syncs withthe selected cell and receives MIB information (3603). According to thepresent disclosure, in order to inform whether the base station supportsMTC terminal, it is proposed to add a predetermined indicator to theMIB, and in case the predetermined indicator is added (3605), theterminal may continue to perform access procedure by identifying thatthe base station transmitting the MIB supports the MTC terminal.However, in case the base station does not support MTC terminal, itdetermines that the corresponding has been blocked and performs aprocedure of selecting other cell (3609). In case it identifies that thebase station supports MTC terminal, the terminal additionally receivesSIB1 and SIB2 from the base station (3607). SIB1 and SIB2 includes PRACHinformation and MTC subbands (3201, 3203, 3205, 3211, 3213, 3215, and3217 of FIG. 32) information of the current base station. The terminalshifts to the random access subband according to the receivedinformation and transmits preamble and receives a response messageresponsive thereto (3611). In case of initial access or reaccess (3613),it finishes the remaining random access procedure according to theconfiguration information included in the response message (3615). Theterminal that has been operating with the base station, as described inconnection with FIG. 10, includes the information on the MTC subbandwhere it used to operate in Msg3 and shifts to the corresponding MTCsubband and finishes the remaining random access procedure (3617).

Having successfully done the remaining random access procedure (3619),the terminal then continues to operate on the corresponding MTC subband(3621), and in case it requires random access in future connected state,includes the information on the MTC subband where it used to operate inthe Msg3 (3617) and operates to continue operation on the MTC subbandwhere it originally used to.

FIG. 37 is a block diagram illustrating an inner structure of a UEaccording to an embodiment of the present disclosure.

The terminal communicates data with a higher layer unit 3710 andcommunicates control messages through a control message processor 3715.The terminal multiplexes control signals or data through a multiplexer3705 under the control of controller 3720 when sending the controlsignals or data to the base station and transmits the data to through atransmitter 3700. By contrast, upon reception, the terminal receivesphysical signals through the receiver 3700 under the control of thecontroller 3720, demultiplexes the received signals through ademultiplexer 3705, and transfers to the higher layer unit 3710 orcontrol message processor 3715 depending on each message information.For example, SIB is such a control message.

Although described is an example in which the terminal consists of aplurality of blocks and each block performs a different function, thisis merely an example, and is not limited thereto. For example, thefunction performed by the demultiplexer 1205 may be performed by thecontroller 1220.

FIG. 38 is a block diagram illustrating an internal structure of a basestation according to an embodiment of the present disclosure.

Referring to FIG. 38, according to the present disclosure, the basestation may include a transceiver 3805, a controller 3810, amultiplexing and demultiplexing unit 3820, a control message processor3835, various higher layer units 3825 and 3830, and a scheduler 3815.The transceiver 3805 transmits data and a predetermined control signalthrough a forward carrier and receives data and a predetermined controlsignal through a backward carrier. When multiple carriers areconfigured, the transceiver 3805 conducts communication of data andcontrol signals through the multiple carriers. The multiplexing anddemultiplexing unit 3820 multiplexes data generated in the higher layerunits 3825 and 1330 or the control message processor 3835 ordemultiplexes data received from the transceiver 3805 and transfers theresultant data to a proper higher layer unit 3825 and 3830, the controlmessage processor 3835, or the controller 3810. The control messageprocessor 3835 may process control message transmitted from the UE andperform necessary operations, or generate control messages to betransferred to the UE and transfer the control messages to a lowerlayer. The higher layer units 3825 and 1330 may be configured per UE orservice, and may process data generated in a user service such as filetransfer protocol (FTP) or voice over Internet protocol (VoIP) totransfer the same to the multiplexing and demultiplexing unit 3820 orprocesses data transferred from the multiplexing and demultiplexing unit3820 to transfer the same to a higher layer unit's service application.The scheduler 3815 allocates a transmission resource to the UE at aproper time considering, e.g., the buffer state, channel state, andactive time of the UE and processes the transceiver to process thesignal transmitted from the UE or to transmit a signal to the UE.

The use of the method proposed enables seamless communication andsupport of random access so that the MTC terminal supportive ofnarrow-band frequency may access the base station operating at awideband frequency.

Meanwhile, as a web application programming interface (API) called webreal-time communication (WebRTC) has been standardized, users happenedto be able to make calls (real-time communication) through a browserwithout the need of installing a plugin for the browser or a separateapplication. A user (sender) may download a web application through thebrowser and may make a call using the identity (ID) of the recipientalready known to the sender. Here, the recipient needs to havedownloaded the same web application as that used by the sender or a webapplication at least interoperable with the sender's web applicationthrough his browser in order to receive the call.

The above-described basic WebRTC based calling is limited. For example,particular web applications should have been downloaded through thebrowser for calling and receiving. Simply speaking, calling andreceiving are required to access a particular website and login (someweb sites do not require login depending on their features). From anormal perspective where the sender and the recipient do not previouslyagree on downloading a particular web application through their browsersbefore calling, such limitation is quite bothering.

To address such limitation, the 3GPP, since Release 12, has conductedthe work that enables the use of the IMS of the legacy mobilecommunication network through WebRTC. The core idea of this work lies inallowing the user desiring to call through WebRTC to register in theIMS. For convenience, the user who registers in the IMS and callsthrough WebRTC is referred to as a WebRTC IMS client (“WIC”).

On the sender's position regarding the effects of the above-describedwork, the targeted recipient is expanded from the browser user who hasdownloaded a compatible web application to common mobile phone users orlandline users. This is true on the position of the recipient. Althoughbasic WebRTC-based calling requires the sender to be the browser userwho has downloaded a compatible web application, the 3GPP work enablescommon mobile phone users or landline users to make a call to therecipient registered in the IMS.

Generally, to register somewhere, the ID of the registering entity isrequired. Likewise, to register in the IMS, an IMS ID is required. TheIMS ID refers to an IMS public user ID (IMPU) and/or an IMS private userID (IMPI). Existing 3GPP release 12 tasks have primarily focused onstandardizing the cases where the WIC may obtain the IMPU, IMPI, and/ortheir relevant IMS authentication information from the terminal/useritself such as the terminal's subscriber identification module (SIM)card and/or user input. However, when the WIC may obtain the IMPU, IMPI,and/or IMS authentication information from the terminal/user itself,calling need not rely on the browser. In this sense, the standardizationloses its utility or applicability.

According to an embodiment of the present disclosure, there are proposeda method and apparatus enabling the WIC to call through the IMS andWebRTC without the need of directly obtaining the IMS ID and/or itsrelevant IMS authentication information from the terminal/user.

FIG. 39 is a flowchart illustrating a process of registering to an IMSby a WIC according to an embodiment of the present disclosure.

The embodiment of the present disclosure described in connection with

FIG. 39 may apply to, e.g.,

-   -   the scenario that the WIC having done authentication with the        web server registers in the IMS through an individual IMPU,        and/or    -   the scenario that the WIC assigned an individual IMPU from the        IMPU pool possessed by the web server registers in the IMS.

Hereinafter, embodiments of the present disclosure are described indetail. FIG. 39 illustrates a scenario according to an embodiment of thepresent disclosure.

The user may access the resources of the WebRTC web server function(WWSF) 3910 through the browser. For security purposes, the user mayestablish a connection with the WWSF 3910 through the hypertext transferprotocol over secure socket layer (HTTPS) protocol. The browser maydownload a web application from the WWSF 3910. Accordingly, the WIC 3900may be activated.

In operation 3940, the WWSF 3910 may authenticate the user in its ownmanner or interworking with the WebRTC authentication function (WAF)3915 through at least one of various web authentication schemes. Anexemplary web authentication scheme is to use the user ID and password.The WWSF 3910 and/or the WAF 3915 might not authenticate the user. TheWWSF 3910 may determine the IMPU and/or IMPI to be assigned to the user.The assigned IMPU and/or IMPI may have a semi-permanent or temporaryconnection with the user. For example, the IMPU and/or IMPI assigned tothe user who does not perform web authentication would be highly likelyto be designed to have a temporary connection. In contrast, the IMPUand/or IMPI assigned to the user who performs web authentication mayestablish a semi-permanent connection with the user (or user ID). TheWAF 3915 may issue a token corresponding to the IMPU and/IMPI assignedby the WWSF 390.

The WWSF 3910 may transfer the token issued by the WAF 395 to the WIC3900. The WWSF 3910 may transfer an additional IMPU and/or IMPI assignedto the WIC 3900.

In operation 3945, the WIC 3900 may initiate a safe WebSocket connectionwith the enhanced P-CSCF (eP-CSCF) 3920 for WebRTC. Accordingly, the WIC3900 may be taken as having done the preparation for registering in theeP-CSCF 3920 which is an IMS entity.

In operation 3950, the WIC 3900 may send an IMS registration requestmessage to the eP-CSCF 3920. The registration request message commonlyincludes the IMPU and/or IMPI. When the WIC 3900 receives the IMPUand/or IMPI from the WWSF 3910 in operation 3940 or obtains the IMPUand/or IMPI from the token received from the WWSF 3910 in operation3940, it may put the IMPU and/or IMPI in the registration requestmessage. Otherwise, what information should be sent instead of the IMPUand/or IMPI and how need to be defined. The header field (e.g., usernameheader field) for inserting the IMPI is not necessarily send, filled.However, the header field (e.g., To, From) containing the IMPU in theregistration request message may oftentimes need to be filled. TheeP-CSCF 3920 may perform authentication using the token in operation3955 described below. To that end, the WIC 3900, if there is the IMPU,may insert the token in the header field that will be filled with theIMPU. Taking an SIP message as an example, the WIC 3900 may generate avalue to fill the To and/or From header field using the token.

In operation 3955, the eP-CSCF 3920 receiving the registration requestmessage from the WIC 3900 may obtain the token. The eP-CSCF 3920 maydetermine whether the token is valid. To verify the validity of thetoken, the eP-CSCF 3920 may interwork with the WAF 3915. When the tokenis valid, the eP-CSCF 3020 may extract the IMPU, IMPI, WAF 3910 ID, WWSF3910 ID, and token's lifetime from the token.

In operation 3960, the eP-CSCF 3920 may fill the To and From headerfields of the REGISTER message to be transferred to the I-CSCF 3930 withthe IMPU extracted from the token. The eP-CSCF 3920 may fill the username header field of the REGISTER message to be transferred to theI-CSCF 3930 with the IMPI extracted from the token. Although the WIC3900 has sent the header field while it is filled, the eP-CSCF 3920 mayrewrite the header field with the information extracted from the token.As can be seen from the fact that the token's lifetime can be extractedfrom the token, the token has the lifetime assigned by the WAF 3915having issued the token. When the token's lifetime expires, the IMPUand/or IMPI extractable from the token may be reassigned. This may bedone by adjusting the IMS registration maintain time of the WIC 3900.The eP-CSCF 3920 may set the token's lifetime extracted from the tokento the value of the expires header field of the REGISTER message (if theWIC 3900 transfers the registration expire time in operation 3950, thesmaller of the registration expire time and the token's lifetimeextracted from the token may be set). The I-CSCF 3930 may transfer theREGISTER message to the S-CSCF 3930.

In operation 3965, the I/S-CSCF 3930 may send a 200 OK message. Thismessage may include the IMPU and/or IMPI.

In operation 3970, the eP-CSCF 3920 may transfer the 200 OK message tothe WIC 3900. In case 200 OK message includes IMPU and/or IMPI, WIC 3900stores the same and may use IMPU and/IMPI forre-registration/cancellation/session management message related to theregistration in the future. If none, the WIC may use token inconfiguring re-registration/cancellation/session management messagerelated to the registration. The 200 OK message may include theregistration expire time value set in operation 3960 by the eP-CSCF3920. When the registration expire time expires, the WIC 3900 releasesthe registration in the IMS and may inform the WWSF 3910 that theregistration expires. As described above, the WWSF 3910 may newly assignthe IMPU and/or IMPI.

It will be appreciated by one of ordinary skill in the art that thepresent disclosure may be implemented in other various specific formswithout changing the essence or technical spirit of the presentdisclosure. Thus, it should be noted that the above-describedembodiments are provided as examples and should not be interpreted aslimiting.

In the above-described embodiments, all of the steps or messages may beoptionally performed or omitted. In each embodiment, the steps andoperations in the steps may not inevitably be performed in sequence, andmay be performed in reversed order. Transfer of messages may notinevitably be performed in sequence, and may be performed in reversedorder. Each step and message may be independently performed.

Although specific embodiments of the present disclosure have beendescribed above, various changes may be made thereto without departingfrom the scope of the present disclosure. Thus, the scope of the presentdisclosure should not be limited to the above-described embodiments, andshould rather be defined by the following claims and equivalentsthereof.

What is claimed is:
 1. A method for transmitting control information ina wireless communication system, the method comprising: generating aheader including a plurality of MAC subheaders and a medium accesscontrol (MAC) control information including a control field indicatingwhether there are included information related to a power headroom for aprimary cell (PCell) and information regarding secondary cells (SCells)reportable to an extended power headroom; and transmitting a payloadincluding the MAC control information and the header, wherein thecontrol field indicating activation or deactivation of at least one ofthe SCells.
 2. The method of claim 1, wherein one of the plurality ofMAC subheaders indicates presence of the MAC control information.
 3. Themethod of claim 1, wherein the number of SCells is
 32. 4. The method ofclaim 1, further comprising determining an activation/deactivationmedium access control control element (A/D MAC CE) format to be used toactivate or deactivate at least one SCell according to one of a firstrule and a second rule.
 5. The method of claim 4, wherein the first ruleis that when the number of remaining SCells other than a Wi-Fi SCell isseven or less, a legacy A/D MAC CE format is used, and when the numberof the remaining SCells exceeds seven, an extended A/D MAC CE format isused.
 6. The method of claim 4, wherein the second rule is that when ahighest SCellIndex value of remaining SCells other than a Wi-Fi SCell isseven or less, a legacy A/D MAC CE format is used, and when the highestSCellIndex value exceeds seven, an extended A/D MAC CE format is used.7. An apparatus for transmitting control information in a wirelesscommunication system, the apparatus comprising: a controller generatinga header including a plurality of MAC subheaders and a medium accesscontrol (MAC) control information including a control field indicatingwhether there are included information related to a power headroom for aprimary cell (PCell) and information regarding secondary cells (SCells)reportable to an extended power headroom; and a transmitter transmittinga payload including the MAC control information and the header, whereinthe control field indicating activation or deactivation of at least oneof the SCells.
 8. The apparatus of claim 7, wherein one of the pluralityof MAC subheaders indicates presence of the MAC control information. 9.The apparatus of claim 7, wherein the number of SCells is
 32. 10. Theapparatus of claim 7, wherein the controller determines anactivation/deactivation medium access control control element (A/D MACCE) format to be used to activate or deactivate at least one SCellaccording to one of a first rule and a second rule.
 11. The apparatus ofclaim 10, wherein the first rule is that when the number of remainingSCells other than a Wi-Fi SCell is seven or less, a legacy A/D MAC CEformat is used, and when the number of the remaining SCells exceedsseven, an extended A/D MAC CE format is used.
 12. The apparatus of claim10, wherein the second rule is that when a highest SCellIndex value ofremaining SCells other than a Wi-Fi SCell is seven or less, a legacy A/DMAC CE format is used, and when the highest SCellIndex value exceedsseven, an extended A/D MAC CE format is used.
 13. A method for receivingcontrol information in a wireless communication system, the methodcomprising: receiving a broadcast message, the broadcast messageincluding at least one or more bits indicating whether to support arepetitive transmission count of narrowband and system information;identifying whether a first cell supports narrowband and/or enhancedcoverage; and when the first cell supports the narrowband and/orenhanced coverage, receiving system information based on the repetitivetransmission count.
 14. An apparatus for receiving control informationin a wireless communication system, the apparatus comprising: a receiverreceiving a broadcast message, the broadcast message including at leastone or more bits indicating whether to support a repetitive transmissioncount of narrowband and system information; and a controller identifyingwhether a first cell supports narrowband and/or enhanced coverage, andwhen the first cell supports the narrowband and/or enhanced coverage,receiving system information based on the repetitive transmission count.15. A method for receiving control information in a wirelesscommunication system, the method comprising: receiving systeminformation, the system information including information regardingfrequency hopping and multiple physical random access channel (PRACH)resource sets; and determining a radio resource to be used for apreamble to be used based on the system information.
 16. The method ofclaim 15, wherein the system information includes at least one of systemcapability information including an indicator indicating whether a basestation may support a machine-type communication (MTC) terminal andrepetitive transmission information including a count of repetitivetransmission of a symbol information block (SIB) for MTC.
 17. Anapparatus for receiving control information in a wireless communicationsystem, the apparatus comprising: a receiver receiving systeminformation, the system information including information regardingfrequency hopping and multiple physical random access channel (PRACH)resource sets; and a controller determining a radio resource to be usedfor a preamble to be used based on the system information.
 18. Theapparatus of claim 17, further comprising the system informationincludes at least one of system capability information including anindicator indicating whether a base station may support a machine-typecommunication (MTC) terminal and repetitive transmission informationincluding a count of repetitive transmission of a symbol informationblock (SIB) for MTC.
 19. A method for transmitting control informationin a wireless communication system, the method comprising: receivingsystem information; selecting one of random access preamble sets basedon at least one of the system information and signal qualityinformation; randomly selecting a random access preamble from theselected random access preamble set; and transmitting the selectedrandom access preamble to a base station through a random accesschannel, wherein the system information indicates whether the basestation supports a machine-type communication (MTC) terminal.
 20. Themethod of claim 19, wherein the system information includes at least oneof PRACH information and MTC subband information of the base station.21. An apparatus for transmitting control information in a wirelesscommunication system, the apparatus comprising: a receiver receivingsystem information; a controller selecting one of random access preamblesets based on at least one of the system information and signal qualityinformation and randomly selecting a random access preamble from theselected random access preamble set; and a transmitter transmitting theselected random access preamble to a base station through a randomaccess channel, wherein the system information indicates whether thebase station supports a machine-type communication (MTC) terminal. 22.The apparatus of claim 21, wherein the system information includes atleast one of PRACH information and MTC subband information of the basestation.
 23. A method for transmitting control information in a wirelesscommunication system, the method comprising: receiving a token obtainedfrom a web server from a terminal; identifying validity based on thetoken; and after identifying the validity, transmitting an authenticatedregistration request message.
 24. The method of claim 23, wherein thetoken is included in a session initiation protocol (SIP) message and isreceived through a web socket connection.
 25. The method of claim 23,wherein the token is included in a To header field and From header fieldof the SIP message.
 26. An apparatus for transmitting controlinformation in a wireless communication system, the apparatuscomprising: a receiver receiving a token obtained from a web server froma terminal; a controller identifying validity based on the token; and atransmitter, after identifying the validity, transmitting anauthenticated registration request message.
 27. The apparatus of claim26, wherein the token is included in a SIP message and is receivedthrough a web socket connection.
 28. The apparatus of claim 26, whereinthe token is included in a To header field and From header field of theSIP message.